Title: Why I Decided Not to Use Kubernetes

---

May 2, 2016 felt like a crossroads. The container wars were nearing their conclusion with Kubernetes emerging as the clear winner, but there was still so much noise around it. Helm and Istio had just come out and people were excited about serverless, but I was more interested in the infrastructure challenges we faced.

Our team at the time had been using a mix of OpenShift and Docker Swarm for containerizing our applications. We loved the simplicity of Swarm, but found ourselves missing some advanced features Kubernetes offered, like stateful services and better integration with storage. However, every day seemed to bring new Kubernetes problems: networking issues, flaky cluster updates, and the complexity just kept piling up.

One morning, I woke up and realized that while Kubernetes was a powerful tool, it felt like we might be adding more work than it solved. The setup alone was a nightmare—there were so many moving parts to manage, from etcd to network policies, not to mention managing certificates and the authentication mess.

I started asking myself: Is this really worth it? And I had to admit that while Kubernetes provided some amazing features, there wasn’t an immediate justification for us to switch. We didn’t have any stateful applications that required the kind of persistence Kubernetes could offer. In fact, our current setup was working just fine and we were seeing steady progress with new deployments.

I shared my thoughts in a meeting with the team and was met with mixed reactions. Some engineers felt that Kubernetes was the future and that we should embrace it even if it meant more work now. Others agreed with me, suggesting that sometimes simplicity is better than complexity. In the end, we decided to stick with our current setup for now.

But this decision wasn’t easy. I spent a lot of time arguing both sides in my head. On one hand, Kubernetes offered future-proofing and scalability; on the other, it seemed like too much overhead given our current needs. Plus, there was the nagging thought that not leveraging the latest tech might make us look outdated.

In the end, practicality won out. We decided to stick with what we knew worked well enough, while keeping an eye on Kubernetes as a future option. We wanted to ensure that our focus remained on delivering value to our customers rather than getting lost in technical debates about orchestration tools.

It’s funny how these decisions shape your path. Looking back, I’m glad we didn’t dive headfirst into Kubernetes just because it was the latest and greatest. Sometimes, staying true to what you know works can be a better choice than chasing trends.

So there you have it: on this day in 2016, I decided not to use Kubernetes—at least for now. What about you? Have you ever stuck with an older technology because of its simplicity?