There, I said it! Containers won’t fix every application, they won’t replace your server farm, and sadly they won’t do your laundry.

Someone needed to say something in this world of marketing buzzwords and hype machines. “I volunteer as tribute.”

I work with a lot of container tools and platforms, and I have to say the technologies are fantastic! However, I was a SysAdmin for about a decade and worked in the MidWest to boot. (I say that because technology in the United States seems to start on the coasts and works its way to the middle of the country.)

Containers DO serve a great purpose: they isolate a running application into isolation and only give access to host resources that are absolutely necessary.

Containers DO make it easy to try out new technologies and applications. My home lab runs several web hosting tools (like WordPress and Hugo), gaming platforms, and home automation tools. To figure out which ones I liked best, I could spin up a basic image with a couple of commands.

Containers DO allow you to create applications that are self-healing, that can be deployed through automated pipelines, and provide for a dense application population.

However…

Containers DON’T replace the operating system. Guess what? The code running in containers is still Linux (and some are a few Windows images too). The orchestrator or operating system running underneath your container… an OS! The only question is how deeply that OS is obfuscated away.

Containers DON’T have a migration path like P2V (physical-to-virtual) did in the dawn of virtualization.

Containers AREN’T designed to absorb your 100GB legacy application that runs on an antiquated code base.

However…again…

I will say container technologies have come a long way in the last few years. The routes to production have become much more straightforward and more opinionated.

Container technologies are no longer the Wild West. So, while containers may not be a one-size-fits-all solution like the hype machine would have you believe, I do think there are a growing number of use cases.

I picture a long highway that stretches past the horizon. Each exit is a different stopping-off point for an individual workload. For instance:

Exit 1) Maybe you are a small business with a web server, a sales portal, and a backend database. Do you really need a 6-node Kubernetes cluster hosted on a cloud provider? I’d say not.

In this scenario, running a single server (with automated backups, of course) and running your workloads in a series of Podman pods would make sense.

Exit 2) At some point, you decide you want to start adding features to your sales application. Now, you may add 2 or 3 more servers to serve as Dev and QA environments. 

This exit is a little more crowded, but you can still get by with managing your container infrastructure by hand. 

Exit 8A) Let’s say your small sales company expands at a rapid and unanticipated rate. Your 3-4 pods with a couple of containers each are now at over a hundred pods with multiple containers each. You have measurable ebbs and flows of traffic throughout the day.

Do you really want to run each pod by hand? Do you really want your applications to run at peak capacity at 3 AM when you get no traffic to your web properties?

Now we start talking about container orchestration. Now we start discussing bringing in Kubernetes. Now you can build each of dozens of components by yourself, or you can look at the next exit:

Exit 8B) Each cloud provider has their own managed (read opinionated) implementation of Kubernetes, where all the hard decisions are made for you. 

All your operations teams have to do is spin them up, instantiate some users, and start deploying (grossly over-simplified, but you get the idea).

In fact, my company, Red Hat, has one of the coolest (in this dude’s opinion) container platforms out there: OpenShift! 

While I am just a Linux SysAdmin at heart, I can genuinely appreciate what containers and platforms like Kubernetes and OpenShift are trying to accomplish.

I host a live stream on Twitch and YouTube to talk about Red Hat Enterprise Linux. This next week, January 11th, we’re having some of the OpenShift team on to talk about running virtual machines on their platform! (See the comments for the link.)

I am in love with containers; my home lab lives by them. I believe it is necessary to take a realistic approach to move into the container space. One size does not fit all.

——

Disclaimer: This is an opinion piece of my own making. It is neither sponsored nor commissioned by Red Hat.