Introduction to Containerization

The biggest, most complicated, most microservices-y organization I ever worked at didn't use containerization, and didn't want to use containerization. It also had the most smoothly-running system I've ever seen.

But they also had a very strictly controlled run-time environment. There was typically only one set of run-time dependencies that was consistent on all servers and in dev. Meaning that all services could be spun up and spun down on any server, without having to worry about fancy wrappers to make sure that they could maintain their own special snowflake needs that were incompatible with everyone else's special snowflake needs. But it also meant that developers couldn't create special snowflake needs, which in turn meant that taking on a new dependency wasn't a simple package manager operation; it involved coordination with operations and perhaps across many product teams.

As draconian as it sounds, for the most part everyone there loved it. It was just such an easy place to work, because the whole IT situation was uncannily straightforward and simple and consistent.

By contrast, I have also seen a company whose employees I could count on one hand, with a fairly small and tightly focused product, that absolutely needed to be Dockerized. Primarily because every single component was written in a different language, or a different version of the language, or used a different NoSQL datastore, etc. And at that point, with that much mix, you absolutely need some way to layer a consistent abstraction on top of all of it. Otherwise you'll be spending all your time fiddling with environment issues.

- You have heard or said the words "Hmm, it worked on my machine"

- You run or want to run multiple applications on the same host

- You care about software supply chain

- You think serverless patterns may apply to your workloads

- Scheduling applications on to your infrastructure is manual

Containerization isn't perfect, and has its own challenges. There will be growing pains as you move to it, especially if most the team is unfamiliar with the technology. If you try to push it before people perceive (for themselves) that they are experiencing some of the problems that it's designed to solve, then, on top of all that, you're going to have an audience that sees it as a solution in search of a problem.

Conditions like that are just about perfect for kicking off a chain of events that leads to yet another "Containerization is the worst idea ever, never containerize anything" blog post entering the world.

The advantage is that I’d quietly figured out the pain and process so it was smooth sailing for them when they started using it.

After that, it was not difficult to start talking about using containers for CI and production.

Some people prefer this because it's easier to understand what people are spending their time on. Whereas the cracks and seams of sharing work as a team grows are harder to identify. There's lots of an hour or two lost here because of a merge conflict or a half day there because the django project won't start up unless it can find redis.

The question for you is where are you in your product lifecycle? Are you in a place where you can take several people off of feature development and maintenance and dedicate them to, essentially, DevOps? Were you hiring with that in mind? Are people on your team interested in moving to that kind of work?

I really don't think there should be that many cracks in a 12-person dev team that drive a technical need to use containers (or SOA, for that matter).

It's an internal project? What is the uptime and DR requirements for it?

It might not be worth dockerizing if you don't need to scale out. Is it a traditional project that can just scale to larger machines as needed? Can you just run on multiple static environments for development?

If you are making something that needs to autoscale on kuberneties, do real CI (not just continuous build), etc, then sure.

When it does, half-joke Y'know, that wouldn't happen with a container!