Architecture efficiency with containers

What is a container in development terms?

What is a container, you ask? Simple: In terms of your system architecture and development environment, a container is just a contained process.

Just as there are many ways to store and organize data, there are many ways to store processes and applications. One of the best ways is to use containers. In our context, we’ll be looking at containers from a Linux kernel. So, it might help to think of a container as a CHROOT. A CHROOT is kind of like a jail for your process. You put your process in jail and, while there, it cannot access any processes outside of the jail. It will only access file systems that were provided to it at the time the jail was constructed.

Now, let’s talk about what containers are not. Containers are not Docker. Docker often gets all the container credit, but the core container technology isn’t provided by Docker, it’s provided by the Linux kernel itself. However, we like Docker, it’s open source and it makes interacting with Linux containers fun and easy.

What are namespaces and why were they invented?

CHROOTs on their own are not enough. It’s not efficient to only have contained processes that can’t access any external information after the container was created. And so, to improve upon them, kernel namespaces were born. Namespaces are excellent at isolating processes. Once isolated, all processes sharing a network namespace can see and use the same network interface to communicate with one another.

Namespaces don't really have anything to do with “names”, but they do deal with isolating resources in a designated space. For example, processes running in Linux can typically see and interact with other processes because they don't exist in a namespace. But once we start a process in its own namespace, it can only see other processes that are in that namespace. See? Namespaces are like super CHROOTs – or really lenient jails where you can invite your other process friends to hang out, if we stick with our prison analogy.

If you’re thinking, “Hey! This Linux kernel business sounds like a hypervisor,” props for being familiar with hypervisors. Hypervisors are just programs used to manage multiple virtual machines on a computer, but even though there are similarities between containers and virtual machines, they are not the same. Containers are just processes running in a namespace.

Namespaces have nonexistent impact on your processes

Namespace technology is perfect for efficiency because it’s so lightweight it’s nearly nonexistent. Almost zero impact to startup time, and zero impact on runtime. There is zero performance hit to running your process in a container as opposed to outside of the container.

Most virtual machines almost always run an entire operating system. Containers on the other hand, usually just run a single process or two. But, because a namespace can have multiple processes, you could run an entire operating system from within a container. However, that's probably a bad idea, as it would be a complete waste of resources.

Containers and cost savings

Ok, now let’s talk about the money saving part of efficiency. At a DOT conference in 2015, John Wilkes gave a talk on the efficiencies that Google attained after moving to containers and container orchestration. He calculated that if Google was to transition back to traditional virtual machines, it would need to build double the number of data centers to run the same workloads.

You can see the potential efficiency advantages of running containers instead of virtual machines. Virtual machines come with the overhead of powering the entire operating system  and supporting processes. Containers  just run your application without getting bogged down by external processes. As a result, you can run many more containers than virtual machines on a single host.

Containers and security

Though cost savings are obvious benefits, you might still be wondering why you should use containers over virtual machines. After all, you’re probably not in the business of building data centers like Google is. And didn't we just say that containers are just processes running on Linux? Shouldn't we run our processes on the operating system without namespaces? Why do we need this namespace-dockery-do nonsense?

The original reason to run a process in a CHROOT was to isolate the application from the rest of the operating system. Remember our jail? This contained setup is to limit access if the application is compromised. If, somehow, a hacker gets in and can execute arbitrary processes, the hacker is limited in what they can do based on the files and tools provided to the CHROOT process.

Containers offer this same security benefit. You don't have to include the entire operating system in your container, you can just include the files and libraries that your application needs to run. Much like a CHROOT, in the case that your application gets hax0red, you give the hacker very few tools to break out of the container or access resources on the network, limiting the damage the hacker can inflict.

Containers and dependency management

Another reason to isolate your application from the operating system is to avoid the complexity of managing many dependencies for the many different applications you might want to run on a single server. Some operating systems might not provide the required dependency, or the dependencies for two separate applications may conflict. This can make installation and management a nightmare. As developers, we usually leave figuring this dependency hell out to SREs – which, it turns out, is a total waste of time.

With a container image, you install only the dependencies that are required for your application to run. This allows you to run many disparate applications on the same server without risk of dependency conflicts.

The good news is that, because of this application isolation, we gain much more flexibility when upgrading dependencies. For instance, if you’re still running Python 2.7 applications – which is no longer an option for install on many of the latest Linux distributions – you can use containers to isolate older applications so you can continue to run Python services. In this scenario, using containers gives us time to port our applications to Go or Python 3, without compromising our underlying operating system.

Deployment consistencies and happy developers

“It worked on my box” is a common phrase used by angry developers everywhere. But with container images, you can rely on the fact that the image that was built and run on your local machine (or in CI) is the same image that will be tested by QA and the same image that will eventually make it into the production environment. This not only solves efficiency problems in application development but carries them over to production.

Final thoughts

Sing out, Louise! Containers are just processes running in a namespace. But that doesn’t make them trivial. When building an efficient architecture, containers not only help with organization and isolation, but with security, and that’s a lot of bang for your buck.

Find this interesting? So do we! We love to get down and geeky with specific topics like this. Be sure to subscribe to our newsletter for more insights and dev deep dives.