Beyond Docker—Containers, Take 2
Everyone in the development community seems to be talking about nothing but Docker Containers these days. Given the high degree of interest in the development community to develop architectures and deployment tools that can spin up new applications faster than ever in virtualized and cloud environments, it is time to dig deeper into what all the fuss is about.
While Docker has grabbed all the headlines, there are plenty of other companies and projects that have been pursuing similar ideas and architectures for a very long time. The granddaddy of all things related to containers is, of course, chroot, which was added to BSD Unix back in 1982.
Chroot, which is still widely used for securing webservers, creates discrete private areas within a system, a container, if you will. This allows for complete separation of any program from the operating system and from any other program running in a different area. Chroot has long been considered to be an extremely secure and reliable method of separating applications on a system.
Since 1982, other container type systems were developed including Kupernetes, a Google backed platform, Apache’s Mesos, the OpenStack Magnum project, and Canonical’s LXD. Google has long been a proponent of containers in general. For Google’s use case, needing to stand up many small applications quickly, containerization makes perfect sense.
Mesos takes a frame approach for its solution. Users create frameworks, not dissimilar to Chef’s concept of recipes. LXD is Canonical’s answer to Docker and is of course based on Ubuntu. It is only a few months old, so the jury is still out, but it also came out of the Linux Container Open Source project (LXC). And finally, OpenStack is getting into the act with the Magnum project, which is touted as Containers as a Service.
Containers are essentially a way to speed the creation of new applications by changing only the non-standard elements in the application environment—think of them as the processes in older terminology. The advantages of the container approach to building applications is faster boot time because it is using a form of para-virtualization by sharing common resources. Any applications where resource elasticity and variable workloads are significant concerns are good candidates for containerization.
Are there any security or performance concerns for companies considering using the technology? As with any virtualized environment that shares resources, there are security concerns at any level of the stack where the resources are shared.
You need to make sure that the containers are well insulated from each other, but given that this is often handled by the cloud provider, most users have little or no say about the security of containers. To get around this issue and also to improve performance, some people are deploying containers on bare metal. However, that seems counterintuitive to the spirit of virtualization.
No matter what container system you decide to use, at the end of the day it is a useful technology—but certainly not industry changing.
