<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Storage on Danilo Falcão da Silva</title><link>https://falcao.org/tags/storage/</link><description>Recent content in Storage on Danilo Falcão da Silva</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 31 May 2026 16:47:01 -0300</lastBuildDate><atom:link href="https://falcao.org/tags/storage/index.xml" rel="self" type="application/rss+xml"/><item><title>Longhorn Makes On-Prem Kubernetes Practical</title><link>https://falcao.org/posts/longhorn-makes-on-prem-kubernetes-practical/</link><pubDate>Sun, 31 May 2026 16:47:01 -0300</pubDate><guid>https://falcao.org/posts/longhorn-makes-on-prem-kubernetes-practical/</guid><description>&lt;p>Everybody who has run Kubernetes on their own hardware knows the
moment the demo ends. You stand up a cluster — &lt;a href="https://falcao.org/posts/rke2-on-prem-kubernetes/">RKE2&lt;/a>,
K3s, kubeadm, whatever fits the rack — and stateless workloads behave
beautifully. Deployments roll, pods reschedule, the control plane
self-heals, and for about a week you feel like you&amp;rsquo;ve gotten away with
something. Then somebody needs a database. Or a registry. Or Postgres
for the internal app that the whole company quietly depends on. And
suddenly the question is no longer &amp;ldquo;can Kubernetes schedule this&amp;rdquo; but
&amp;ldquo;where does the data actually live, and what happens to it when a node
dies at 3 a.m.&amp;rdquo;&lt;/p></description></item></channel></rss>