- the history of Linux containers,
- the docker.io tools to leverage LXC and
- dokku, a simple Heroku-compatible single-host PaaS, powered by docker!
Despite being given by different persons, the presentations had a lot of consistency between them, material-wise. For someone like me not working in the DevOps space, there was a lot to catch. The history of LXC made it really easy to identify the current trend occurring in this space, a trend that I would like to mention in this blog post.
But first, let’s quickly go over what is LXC. LXC stands for LinuX Containers. It allows system-level virtualization. It is akin to build the Linux kernel in user mode, that is, run the Linux kernel as a user process, within a Linux environment that also runs the Linux kernel in system mode. Hence you have an isolated kernel in user memory and it can launches processes of its own, encapsulating libraries and binaries within its own namespace. Except that LXC adds extra mechanism to do it properly, and eventually should be most secure. What’s the advantage of such an approach? A quote from Glauber Costa summarizes it well:
“[…] should it be possible for the operating system to ensure that excessive resource usage by one group of processes doesn’t interfere with another group of processes? Should it be possible for a single kernel to
provide resource-usage statistics for a logical group of processes? Likewise, should the kernel be able to allow multiple processes to transparently use port 80?”
Glauber Costa, Parallels (SWSoft / company behind OpenVZ)
So you get a way to virtualize your applications within the system, without the full-blown virtualization engine. Unlike the user-mode kernel method, this one will share the system kernel between the host and virtualized environments. This has great advantages in terms of performance and finer granularity of application’s encapsulation. If you want to know more, take a look at Simon Boulet slides.
So LXC allows finer-grained virtualization. And the DevOps community is using this property to accomplish a trend that is not unfamiliar to the software development community. Both communities need to scale quick and effective on dimensions that were not matched yet in the history of computing.
These trends are expressed with two manifestos that came to life in the past years coming; one manifesto for one community. They share similar end-goals and some of the same techniques: the twelve factor app and the reactive manifesto. The first comes from the DevOps community and the second from the functional programming ‘inspired’ community.
For example, the idea for predictable and secure deployment for DevOps goes as far to say that your deployments should be immutable. That should sound very familiar if you are a proponent of the reactive manifesto. Immutability escapes the more traditional paradigm of shared state and all the implied locking strategies that one need to use to manage concurrent accesses. Chad Fowler wrote an interesting blog entry on the topic of immutability in the DevOps space. In order to scale and avoid side-effects, maximum immutability should be encouraged.
That’s where the advantages of something like docker.io kicks in, as you develop an automated package of self-contained libraries and executables meant for one sole application running on the server. This package can be deployed on any OS that has the proper Linux kernel, which contains the LXC feature. It should be deployed only once. No updates are allowed. When you want to re-deploy, you re-build the entire LXC container with an automated process.
As a last one and quickly, there was an interesting idea thrown by Chad Fowler in his talk in the Rails Israel 2013 conference. He mentions it around 30:55 in this video:
“What if your routes files read like strongly typed functional pattern matching with destructuring and supported federated, heterogenous services?”
The idea is good. Instead of wiring all of the different servers manually and explicitly, we could define the properties a method needs and the server candidates that fit the criteria would get wired automatically. This is a common technique known as pattern matching in the functional community, applied to the DevOps space. Notice a trend? It’s exciting to see all of these change in the past years in a space that looked mostly static on how to do things.
On this final note, I’d like to stress how great the talks were in the DevOps Montreal meetup. I encourage any software developers in Montreal to attend these, even if you do not identify yourself as a DevOp: we all get to do deployments eventually, they tend to be meticulous and annoying. When it happens, you want to do it right.