You know what’s pretty easy nowadays? Throwing a bunch of processes onto a server running somewhere far away. Dozens. Thousands. Millions. As many as you want. This was really, exasperatingly hard just a few years ago. But Amazon Web Service, CenturyLink, and other players have come along to make this pretty painless.
But you know what’s still really hard? Making those processes completely self-contained and yet running on one kernel and manageable from a single interface. This is the problem that Docker was meant to solve.
Brief intro to Docker
Docker chose to address this problem by building a developer-friendly abstraction layer on top of Linux containers (LXC). LXC is a powerful concept, but it simply wasn’t built as an intuitive interface. It’s a pain to use and prohibitively complicated for anyone but the most adept Linux power users.
And so the idea of enabling developers of all stripes to actually use them in a way that gets rid of tons of conceptual overhead and streamlines the use of containers into an actual runtime that makes real sense amounts to a massive win over the more low-level containerization tools that already exist.
Docker takes LXC and constructs a set of basic commands around it, commands that allow you to, for example, see which containers are currently running, attach other processes to containers already running, build a container using a
Dockerfile as a basis (yep, exactly like a
Makefile or a
Vagrantfile), push and pull container images from the Docker repository, start and stop containers, view the logs from the activities of a container, and far more.
I challenge you to look, for example, at the Ubuntu LXC docs and explain to me how to do just about any of the above. Docker is really nothing less than the best interface yet produced to work with Linux containers. It probably won’t be bettered for quite some time.
From the Twelve-Factor App to the Container
In order to begin understanding the implications of Docker for the PaaS space, I think you need to compare it with other approaches.
It’s safe to say that there are a few emerging best practices in how PaaS-friendly apps should be architected. The most succinct expression of the principles behind these practices can be found in the Twelve-Factor App declaration. It does a good job of setting forth what apps should like like in the age of PaaS. The most crucial principle: PaaS-friendly apps need to not care where they are.
This means that configs like API keys and resource handles for databases and other services like message queues need to be stored in the application’s environment rather than in the application’s code. This enables apps to run anywhere that both supports the app’s runtime and has all necessary configs stored as environment variables. But it still requires that they rely on access to something outside of themselves.
Docker explicitly violates this principle of the Twelve-Factor App. Docker apps don’t rely on any external environment. In fact, Docker demands that you store all config values, dependencies, everything inside of the container itself. Apps communicate with the rest of the world via ports and via Docker itself. The trade-off is that apps become a little bit bulkier (though not significantly), but the benefit is apps become maximally portable.
In essence, Docker makes almost no assumptions about the app’s next home. Docker apps care about where they are even less than twelve-factor apps. They can be passed to and fro across servers—and, more importantly, across virtualization platforms—and everything needed to run them (besides the OS) comes along for the ride.
And so what we have here is two competing understandings of what the platform layer of the cloud is even about. The Twelve-Factor App approach was a crucial step in the direction of PaaS as we know it today, but it cannot help but sacrifice portability.
Needless to say, with AppFog I’ve strived to build a platform layer that is cross-cloud to the very core—meaning cross-data center and cross-virtualization—and so I love this vision. I’m confident that the portability-driven approach will win out in the end, and I’m thrilled to see that I’m not alone in having this vision.
Conclusion: Docker and the core mission of PaaS
While it’s always hard to speak counterfactually, I believe that a tool like Docker could have come only from a PaaS inspiration.
IaaS providers are extremely good at a lot of things, but they don’t have the same incentive to produce tools like Docker—or Cloud Foundry for that matter—that platform specialists do. PaaS is about APPS, IaaS is about INFRASTRUCTURE. The mission of the IaaS layer is to get you to use lots and lots of computing resources, not to leverage computing power to maximal advantage (not to mention user friendliness) towards apps.
Tools like Docker and Cloud Foundry are providing all the extras that make the cloud a usable entity, bridging gaps that IaaS has no interest in bridging. It’s a great thing to be a part of.
Docker is young but has already received a number of votes of confidence from the developer community. Flynn.io, for example, is an open source PaaS currently under construction that has Docker as its core basis. Someone has a built a Memcached as a service using Docker. There are a variety of other ambitious projects in the offing. Not bad for a project that went public this year.
The PaaS space is in movement. The very definition of the term platform and what it should offer is in a state of flux. I’m happy to see that others share our basic vision.