$ cat post/vi-on-a-dumb-term-/-we-named-the-server-badly-then-/-we-were-on-call-then.md

vi on a dumb term / we named the server badly then / we were on call then


Title: Kubernetes vs. Old Friends


March 12, 2018 was just another day at the office until I found myself arguing with an old friend. Well, maybe not a real friend, but a piece of software that used to be my BFF.

The Setup

I’ve been working with Docker for a couple of years now, and it’s been an awesome ride. Docker containers were simple to spin up, easy to manage, and offered a neat way to package applications without worrying too much about the underlying OS. But in 2018, I started noticing a new kid on the block—Kubernetes.

The Challenge

One of our projects at work was still using Docker Swarm for container orchestration. We were doing fine, but as we started to scale up and face more complex environments, it became clear that we needed something more robust. Enter Kubernetes.

The migration wasn’t going smoothly. Our team was split between traditionalists who loved the simplicity of Docker Swarm and those eager to embrace Kubernetes. I found myself in the latter camp, but I couldn’t shake off my feelings of nostalgia for our old friend Docker.

The Debugging Session

One day, we were setting up a new cluster using Minikube, and things started to go south. We spent hours trying to debug what seemed like a simple deployment issue. It was frustrating—basically, the pods weren’t starting up as expected. After several failed attempts at diagnosing the problem, I decided it was time for some honest debugging.

I pulled out my trusty kubectl and ran through the usual commands: get nodes, describe pods, logs. Nothing seemed out of place. It was like trying to debug a problem with your old computer—every step felt familiar but nothing fixed it.

Then, something clicked. I opened up the pod logs and saw an error related to network configuration. Aha! It turned out we had missed a critical piece in our Deployment YAML file that defined the container’s network settings. We had used Docker Swarm for so long, the transition to Kubernetes felt like learning a new language with similar but different syntax.

The Realization

After fixing the issue and successfully deploying our application on Kubernetes, I sat back and reflected. This wasn’t just about technology; it was about change management within a team. We had to unlearn some habits and adapt to new ways of thinking. It made me realize that while Docker was a powerful tool, its simplicity came at a cost when dealing with complex environments.

The Lesson

This experience reinforced the importance of continuous learning and staying adaptable in tech. Kubernetes might have won the container war, but it took us a bit longer to fully integrate than we hoped. The journey wasn’t easy, but it was necessary for our project’s growth.

As I write this, I can’t help but think about how quickly the tech landscape changes. Tools like Helm and Istio are now part of the Kubernetes ecosystem, providing even more functionality. Serverless is on everyone’s lips, promising a new way to build applications without worrying about infrastructure. But for now, we’re focused on making our transition as smooth as possible.

Kubernetes might have won the day, but old friends never fully leave us. They come with us through the journey of learning and growth.


That’s where I was in March 2018—between old habits and new technologies, learning to adapt along the way.