I swear I had something to call this post..

It'll come back to me.

Today, I want to talk about containers. You know, actually, I don't: I want to get back to the topic of Why vs How.

At the office this week, there was quite the blow up about Containers. Sure, it was dressed up as 'evolving our infrastructure", but in my humble opinion, it all got very sideways into a vendor discussion with way more alacrity than I'm accustomed to, even though the company I work for is terribly adept at focusing on technology.

The real sin here is that the discussion forgot one really important thing: the technology doesn't exist for no reason. The technology doesn't exist in and of itself, the technology exists to solve a problem that you  have, not to make one.

This really is the recurring theme of my life, and I'm really getting tired of having the same arguments over and over. So, in the spirit on having this argument over and over:

Containers are a how. They are not a why.

Determining the Why that leads you to implement containers is vital.

If you don't appreciate the Why that gets you to containers, you're basically magnifying your underlying problems by 100x when you finally have a container farm full of images that you cant' manage. And if you think troubleshooting problems in today's infrastructure is a headache, wait until it's all containerized and therefore opaque to all the tools and techniques you have half-implemented now.

Without appreciating that the reason you have friction in deployments is a COMBINATION of problems that containers PARTIALLY address, you're flying blind.

Don't fly blind. Mountains don't move.
Don't fly only by radar. Mountains can hide behind systems failures.
Don't fly by sight alone. Humans are fallible.

The only safe thing to do is fly with radar, humans, and in daylight, with a plan that reflects the ground you're flying over. Anything else is a recipe for a mountainside perishing.