$ cat post/chmod-seven-seven-seven-/-the-load-average-climbed-alone-/-the-pod-restarted.md
chmod seven seven seven / the load average climbed alone / the pod restarted
Containers Everywhere… Or Are They?
November 4th, 2013. The air is crisp and the sun sets early over my window at the office in downtown Seattle. A spreadsheet in fewer than 30 lines of JavaScript has just hit Hacker News, sparking a frenzy that will last into next year. It’s the start of something, but what? I’ve been following the container scene closely since Docker released its first version earlier this year, and it feels like we’re at an inflection point.
At work, we’re still in the early stages of deciding whether to embrace containers. Our application architecture is monolithic, and the idea of splitting it into smaller services hasn’t really taken hold yet. But there’s a growing sense that Docker might be the key to unlocking our next big deployment platform. The term “microservices” is starting to gain traction in tech circles, but I can’t help but feel like we’re jumping on another bandwagon.
Last week, one of my developers showed me CoreOS and its container management tools—fleets and etcd. It was fascinating; the simplicity and the promise were hard to resist. But as much as I wanted to dive in headfirst, I couldn’t shake off that nagging feeling that maybe we were making a mistake.
The biggest issue is our infrastructure. Our current setup relies heavily on VMs for isolation and scaling, and changing that is not going to be easy. We have a mix of custom scripts and existing tools like Puppet to manage them, and suddenly the thought of rewriting all that just seemed daunting. Not to mention, we’d need to train everyone on Docker and its ecosystem, which isn’t exactly simple.
I remember when I first heard about 12-factor apps. It was refreshing—something so straightforward yet powerful. But as I started implementing it in our monolithic app, I realized that breaking things down into smaller pieces wasn’t just a matter of refactoring code; it required rethinking how we develop and deploy applications.
Today, I spent the morning arguing with my team about whether to move forward with Docker or stick with what we know. The conversation was heated, but that’s not uncommon around here. My colleague, Alex, brought up Kubernetes, which Google announced just last month. It seemed like a promising solution for managing containers at scale, but it also felt like one more layer of complexity.
In the end, I didn’t have a definitive answer. We decided to take a step back and really assess our needs. Maybe Docker isn’t the best fit for us right now. Or maybe we need to invest in learning how to use it properly first. The decision was made on pragmatism rather than hype.
As I close my laptop, I can’t help but think about Winamp shutting down. It’s a reminder that technology moves fast and what’s cool today might be obsolete tomorrow. But for now, we’ll stick with our tried-and-true VMs and see where Docker takes us.
The tech world is always in flux, and it’s easy to get swept up in the latest trends. But sometimes, taking a step back and focusing on what works best for your own projects can lead to more lasting success than just following the crowd. As we move forward, I hope to find that balance—embracing new technologies while staying grounded in what really matters.
Until next time,
Brandon Camenisch