Title: February 17, 2014 - Docker Fever and the Search for a Better Deployment Tool

---

February 17, 2014. I remember this day well because it was a Thursday when we were discussing whether to jump into the “Docker fever” at work.

At the time, Docker was all the rage—microservices were becoming the buzzword of the DevOps community, and everyone was talking about containers as the future of application deployment. CoreOS had just released etcd and fleet, and Kubernetes was on its way, announced by Google in May 2014. We were excited but skeptical.

Our company was working on a major upgrade to our existing monolithic application that required us to migrate from our current virtual machine (VM) infrastructure to something more lightweight. The idea of using Docker containers seemed like it could be the perfect solution—faster deployments, less overhead, and easier scaling.

But as I sat in the meeting, I couldn’t help but feel a twinge of doubt. We had already invested heavily in VMs and associated tools like Puppet for our CI/CD pipeline. The idea that we might need to rip out an entire ecosystem just because Docker was suddenly “the thing” felt risky.

I started writing down my concerns:

1. VMs vs Containers: While containers seemed lighter, did they really offer a significant enough performance boost over VMs? Would the overhead of running Docker add any noticeable lag in our application?
2. Tooling Maturity: We had been using Puppet for years and trusted it to manage our infrastructure. Moving to Docker meant learning a new set of tools and potentially dealing with less mature systems.
3. Security: With all the hype, I couldn’t help but wonder if we were rushing into something that might not be as secure or stable as what we already had.

I spent the next few days digging deeper into both VMs and Docker. I fired up a local VM using VirtualBox to see how performance compared to running containers. I also started exploring Docker’s ecosystem, looking at etcd for service discovery and fleet for cluster management.

What I found was mixed:

• Performance: In my simple tests, the difference between a lightweight container and a VM was minimal. Containers were indeed faster to start up but didn’t seem to offer as significant of an improvement in terms of raw performance.
• Tooling Maturity: While Docker’s CLI was easy to use, there were still issues with Docker’s ecosystem. The documentation was often outdated or incomplete, and tools like etcd and fleet weren’t quite ready for prime time yet.

By the end of February 17th, I had a clearer picture but no definitive answer. We decided to proceed cautiously—experimenting with Docker in a non-critical part of our application first before making any major changes.

Looking back, it was one of those moments where I felt like I was caught up in a wave of technology hype. But that’s what makes the journey interesting: learning from the mistakes and weighing the pros and cons. In the end, we did migrate to Docker eventually, but only after thoroughly testing and validating its benefits.

That day solidified my belief in taking an iterative approach—giving new technologies a chance but always questioning whether they truly add value over what we already have. And that’s something I still hold onto today as I navigate the ever-evolving landscape of tech.

---

It was a mix of excitement and skepticism, a reminder that not everything that sounds good on paper is worth implementing wholesale. Docker became an integral part of our stack eventually, but it took some soul-searching to get there.