The Benefits of Containers

In the old days, software installation, especially on servers, was a nightmare. Not only did you have to deal with massive installer programs and piles of documentation to get something working properly, but it tended not to be a repeatable process. If you installed software on multiple servers, there was a good chance that one or more servers were improperly configured, resulting in the waste of huge amounts of time troubleshooting. Additionally, it meant that scaling out was much harder and required a lot more work. This tended to mean that companies would spend a lot of money on hardware, simply to avoid spending even more money on salaries when there was a need to scale out. However, tech has evolved. Rather than treating servers like pets that have to be carefully monitored and cared for, we now treat the machines like cattle. They are interchangeable, easily added or removed, and we can quickly get things working in a new environment (at least, compared to how things used to be). As part of this process, we’ve changed our approach to how we deploy code at scale, First, we started with virtual machines, so that we could abstract away the underlying hardware under our applications. While this helped considerably, it wasn’t enough and wasted a ton of resources on duplicate functionality (operating system installations). As we moved further along, we started switching to a container-based approach, preferring to abstract away everything but the operating system kernel. Before we get too far into this, there are some terms we need to discuss quickly. A container is used to host a chunk of code in an isolated environment that only directly interacts with the operating system’s kernel. An image is essentially a template for a container {think about an image being a class and a container being an object – that’s close enough for the purposes of this show, but not for an actual certification test}. Images are built in layers, so you can compose functionality for a new image by utilizing a set of other images, including some that you may build yourself. Images are available from image hubs (like docker hub), where they are versioned and where documentation is available on using them. The host is the machine on which the containers are run. Learning the concepts behind the code we write is important. We often complain or hear complaints about colleges teaching only concepts and not the practical skills. Coding bootcamps are full of college graduates looking to learn practical skills because jobs no longer want a junior with knowledge of concepts but with useable skills. For those of us who didn’t go to college for comp science, the rush to learn the skills can cause us to not take the time to learn the concepts. Learning the concepts allows us to be able to apply the what we learned in one language or framework to the next one we learn. They allow us to move from different skills within programming without having to learn a whole to set. Episode Breakdown Isolation from the rest of system, except for the kernel. This means that each container has its own copy of the very small set of things required to run themselves, without other stuff in the mix. This tends to keep things smaller, and shrink the attack service area. Due to each container having its own copy of any dependencies, you don’t have to worry about an update in another container breaking your container. This also puts a security boundary in place. If another container is compromised, it is less likely to be able to compromise your container. Ability to control resource usage Along with security boundaries, you want to make sure that one container can’t cause a denial of service for other containers on the machine (intentionally or otherwise). Modern container technology allows you to limit how much RAM, CPU,