The Container Revolution: Much Ado About Nothing?

Containers are, broadly speaking, a codified way of ensuring that your IT people never get too attached to their servers. The idea is to use lots of identical containers built off the one master template (the image) so that if any one of them dies (or is killed) you don’t miss it much, and it’s easy to replace with another identical container built from the master image. They're smaller and lighter than virtual machines, but their most important feature is:

They don’t remember anything.

You can alter a container’s state at runtime if you want to – changing configuration or setting up some local data of some kind – but when the container is destroyed all the data is destroyed with it.

This is an important point: it’s when, not if, because the defining characteristic of a container is that it’s relatively short lived, and is destroyed utterly on a regular basis, to be replaced by a shiny new version, un-tainted by any memories of its former self.

That’s actually great compared to other methods of doing software development. If you’ve ever endured the lengthy enterprise processes of the Software Development Life Cycle (Dev/Test/QA, then Change Advisory Board, then scheduling, then GoLive and then scrambling to fix all the issues) you’ll appreciate the pain I refer to.

This lack of state enforces discipline on the people responsible for writing your business software. If everything is built fresh each time, there’s no advantage to quickly changing the configuration settings “just this once” in order to get the build running, or to fix a production problem. That fix will be quickly lost when the container is rebuilt. You can avoid having your Test environment set up differently to QA or Production, and avoid the cries of “Well, it worked in Test” as the reason Internet banking is down today.

Instead, everyone is forced up update the master configuration (dare we call it a CMDB?) with the Way Things Should Be, and then that image is deployed into all of the environment.

Any container that starts to develop personality – a few quirks, some endearing foibles, some hint of a personality that might appear in a heart-warming children’s movie – is quickly dispatched in workmanlike fashion, replaced with a grey clone of the original master image from the cold, heartless archive.

Neat. Clean. Organised.

This enforced discipline makes the entire process of software development and deployment much more streamlined. More mechanised. Building systems becomes much more like a production line than the hand-crafted servers of old.

The thing is, that’s not where all the value to your organisation lives. Much of it lives in the data your organisation has. All the things that don’t get thrown away from day to day, and in fact cannot be thrown away. Sales orders. Bank balances. Ownership records. The whole capitalist system relies on us being able to remember where the money is, and who owes what to whom.

That can’t be stored in a stateless container.

Docker, to use the most famous example of containers, currently has a solution to this problem that it calls storage only containers, but there’s a problem. These containers aren’t really containers, they’re just a sticker on a file-system with the word Container painted on it in big friendly letters. That file-system lives on the Docker host, a server – physical or virtual – like those we’re used to. Keeping that data live and available to the containers requires some sort of non-container solution. A solution that uses… well, what exactly?

Could it be that all our existing knowledge and tools designed around keeping data safe and available can’t be thrown out overnight? After all, we developed backups, and replication, and RAID, and clusters, and Disaster Recovery, and Business Continuity Plans (and a host of other solutions besides) for very good reasons. Those reasons haven’t suddenly gone away because some cloud company did something nerds think is cool.

Right now, there don’t appear to be container specific solutions, but expect some to start cropping up. There’s good money to be made selling shovels in a gold rush, so expect to see some startups offering containerised versions of things we’ve seen before in hypervisor and physical server land.

For my money, while containers do provide something that is genuinely useful, they’re far from the full story and the tools you’re used to using so far will be around for quite a while yet.

This article first appeared in Forbes.com here.