Title: Kubernetes vs. Docker Swarm: A Day in the Life of a Platform Engineer

---

November 21, 2016 was a Tuesday. I woke up to another day of making decisions that would shape how my team operated for years to come. The tech world had just witnessed Donald Trump’s historic election, and while I wasn’t paying much attention to that, the battle between Kubernetes and Docker Swarm was heating up on my radar.

On Monday, we held a brown-bag lunch where we talked about container orchestration tools. A few of us were leaning towards Docker Swarm because it seemed like the easy choice: it’s built by the people who brought us Docker, after all. But I had some reservations. The community around Kubernetes was growing rapidly, and Helm, Istio, Envoy—all these new tools and concepts—were starting to make an impact.

I was skeptical. Could we really afford to dive into such a complex ecosystem just to have more flexibility down the line? And let’s not forget about serverless. It was all so… promising, but also overwhelming.

Later that day, I spent some time with our developer team. We had been using Docker for local development and containerized applications, but we hadn’t fully embraced orchestration yet. They were happy with what they knew: docker run commands and the occasional docker-compose.yml.

But as a platform engineer, I couldn’t just rest on our laurels. We needed to future-proof our infrastructure. So, I argued that Kubernetes offered us more than just orchestration; it was about having a robust ecosystem that could evolve with our needs.

The day went on, and we debated the pros and cons of each tool. Swarm seemed simpler to set up initially, but Kubernetes promised better long-term scalability. The team had valid points too—they were already familiar with Docker commands, making the transition to kubectl feel like walking into a new world.

Around 5 PM, I decided to do some research on my own. I fired up my laptop and started looking at Kubernetes documentation. I found myself spending an hour configuring a local cluster using Minikube, just for kicks. It was rough—trying to get the kubeconfig file right, figuring out how to deploy apps with kubectl. But there it was: a working, albeit small, Kubernetes cluster running on my machine.

I realized that while Swarm might be easier now, the cost of switching later could be too high. We needed something that would let us scale up and handle more complex workloads without rewriting everything from scratch. Kubernetes felt like the way to go.

By 6 PM, I had a plan: we’d start with a proof-of-concept using Minikube. If it worked out, we’d gradually move our development environment over, starting with non-critical services first. And if anything went south, we always had Docker Swarm as a fallback.

I hit the ‘Save’ button on my document and got up from my desk. My colleagues were finishing their work, too. I felt a mix of excitement and nervousness. Excitement because this was a big step forward for us, but nervous because change is never easy, especially when it comes to deploying and managing containerized applications.

As I walked out the door that evening, I couldn’t help but wonder how many times in my career I would be making similar decisions—choosing between two competing technologies, weighing benefits against costs, and navigating the complexities of change. But that was the job, wasn’t it? To keep moving forward, even when it felt like we were stepping into uncharted territory.

---

That night, as I lay down to sleep, I thought about the journey ahead. Kubernetes or Swarm? Easy choice in hindsight, but a tough call at the time. Regardless of which path we chose, one thing was certain: our platform would evolve, and so would I.