Title: Docker Daydreams and a Bit of SRE Realism

---

May 19, 2014. A Monday morning that felt like any other, but the tech world was stirring with containers, microservices, and Kubernetes. I spent most of my time in a server room, dealing with legacy systems and trying to fit Docker into our existing infrastructure. It’s not often you get to be on the edge of something as exciting as containers, but the reality is that there’s still a lot of hard work ahead.

The Docker Daydream

You know how it feels when a new technology comes along that just seems right? Like it fits the problem space so well, and all your instincts tell you, “Yes, this is the way to go”? That’s how I felt about Docker. The idea was simple: lightweight containers for easy deployment and scaling. It promised to be a game-changer, but in practice, it came with its own set of challenges.

I spent the weekend trying out various Docker setups on my local machine, dreaming about the possibilities. By Monday, I had a basic cluster running on CoreOS, etcd, and fleet. But when I tried to integrate this with our existing Kubernetes setup, things didn’t go as smoothly as I hoped. There were compatibility issues, network troubles, and just plain old bugs that made me want to pull my hair out.

The Real World

You know the saying, “In theory, practice is perfect; in practice, theory is imperfect”? Well, this was it. The Docker dream was great, but implementing it in a production environment? Not so much. We had some heated discussions about whether we should be running Kubernetes or Docker containers for our services. Some argued that Docker’s promise of portability and ease would make our lives easier down the line. Others worried about the complexity and potential performance hits.

One of the biggest challenges was figuring out how to manage state with Docker. Our applications needed persistent storage, but Docker isn’t designed to handle this natively. We had to come up with a strategy for storing data outside the container while ensuring it could be easily moved or replaced if necessary. It wasn’t easy, and we ended up implementing a custom solution using etcd and a shared filesystem.

The SRE Factor

On top of all this, I was reading through Google’s SRE book. It hit me that what we were doing wasn’t far off from the practices described in the book—monitoring, logging, incident response—but on a much smaller scale. The idea of Service Level Objectives (SLOs) and service level indicators (SLIs) seemed relevant to our situation, but implementing them for all our services was daunting.

I started sketching out how we could apply these concepts to our existing infrastructure, but it quickly became clear that the tools available weren’t quite there yet. We were still relying on custom scripts and homegrown solutions for monitoring and alerting. It was a reminder that while Docker and Kubernetes promised a lot, they didn’t solve everything.

Lessons Learned

By the end of the week, I had to admit that Docker wasn’t going away anytime soon. The ecosystem was growing rapidly, and more tools were emerging to address its shortcomings. We decided to take a hybrid approach—using Docker for new services while keeping our existing infrastructure intact for now. It wasn’t ideal, but it gave us time to refine our practices without disrupting the entire system.

Reflecting on the week, I realized that while we’re constantly chasing new technologies and best practices, there’s still a lot of groundwork to do. The 12-factor app principles made sense in theory, but applying them across a complex infrastructure was no easy feat. It’s moments like these that remind me why SRE is so critical—not just for handling incidents, but also for shaping the way we think about and build our systems.

---

That’s where I left it on May 19, 2014. The journey of integrating Docker into our infrastructure was far from over, and neither were my daydreams. But reality was always going to be a little messy.