Docker ascendancy's ignites a flak-in-the-box cloud arms race

Web lessons in bullet-proofing the container class

Ship it good

Docker lets developers do the same with code. In the shipping metaphor, your applications and code are the goods, the Docker images are the containers and the ship is the server, virtual server or cloud where you're deploying your application. The server can just stack Docker images up without ever worrying about what's inside them.

Another way to think of a container is that it's a virtual machine without the operating system. It's a container that holds applications and all their prerequisites in a self-contained unit, hence the name. That container can be moved from one machine to another, or from virtual to dedicated hardware, or from a Fedora installation to Ubuntu and it all just works.

Or at least that's the latest wave of the "write-once-run-anywhere" dream that Docker has been riding to fame for the past two years. The reality, of course, is a little different.

Imagine if you could fire up a new virtual environment on your Linux laptop, write an application in Python 3 and then send it to your co-worker without needing to worry about that fact that she's running Windows and only has Python 2 installed. If you send her your work as part of a container, then Python 3 and all the elements necessary to recreate the environment you were working in come with your app. All she has to do is download it and run it using Docker's API interface.

Then, after your co-worker finishes up the app you can pull in her changes and send the whole thing up to your company's AWS EC2 server, again not worrying about the OS or environment particulars other than you know Docker is installed.

But there's the rub – your app is now tied to Docker, which in turn means the future of your app is tied to the future of Docker.

From a high-level view, what Docker does is nothing new. Linux containers have been part of the kernel since 2008, but Docker has packaged up a very slick system for quickly and easily creating, running and connecting lightweight Linux containers. With Docker you don't need to configure a whole new virtual machine every time you want another instance.

But this doesn’t make Docker a panacea. Not yet, anyway. The containerisation of all the things has a few flaws in its current form. The good news is Docker is no longer the only story in the world of containerisation. Competitors like Joyent and Canonical have both open sourced their own take on the containerisation concept. The latter's take is particularly interesting since it focuses much of its efforts on security. Canonical's effort is two-fold, focusing on built-in tools like LXC (pronounced "lex-cee"), the client, and LXD (pronounced "lex-dee"), the server. Given that Canonical's Ubuntu OS is the basis of many Docker containers out there, a system specifically optimised for that set-up will no doubt have appeal.

Another rapidly growing take on containerisation is Rocket, created by the developers behind CoreOS. Rocket launched with a rather inflammatory post from the CoreOS developers claiming: "Docker is fundamentally flawed." The post calls out Docker for being insecure, but the main difference really comes down to... Ready for it? Systemd.