When Would We Use a Container Over a Virtual Machine or a Process?
This is a valid question, especially considering the fact many companies have heavily invested in virtualized environments on premises and in the cloud. Hypervisor virtualization technologies have proven to be secure and compatible, and we could even look at a virtual machine as an encapsulated, individually deployable component.
The answer to this question really lies in the scenario. Not every scenario should, or even can be, solved with containers, so it is important to understand where containers are a good choice over virtual machines.
Let’s have a closer look at a scenario that enables us to compare virtual machines and containers.
Consider a cloud service that needs to calculate the average rating for a given picture. In large social networks or picture-sharing applications, the average rating does not need to be updated immediately after a user has rated the picture. It is sufficient if the average rating is updated once or twice a day.
A good technical and economical way of implementing periodic tasks is to run a background job on an existing compute cluster. This background job only needs to run once or twice a day, for a short period of time, and then immediately terminate.
If we used a virtual machine for this job, we would not want to have it up and running all the time as this incurs unnecessary costs. One way of implementing this scenario is to start a virtual machine instance on demand when the job needs to run. Although that sounds good, there are a few issues to consider.
First, the virtual machine can take a considerable amount of time to start—there is a full operating system to boot. There are times when booting the VM takes longer than the actual runtime of the job.
Second, the size of the virtual machine can be an issue. A virtual machine contains an entire operating system, which can easily be several gigabytes in size. For example, the Windows Server-based Visual Studio virtual machine images in the Azure gallery are all more than 128GB in size. Copying this image across a network, if they are kept in a central image repository for example, will take a lot of time.
Third, scaling of virtual machines has its challenges. Scaling up virtual machines requires a new, larger virtual machine (more CPU, memory, storage, and so on) to be provisioned and booted. Scaling out also runs into the startup time problems of virtual machines. In our example, the second virtual machine can take longer to provision and boot than to run the actual job, resulting in it coming online too late.
Another consideration is the economics of virtual machines. Virtual machines use considerable amounts of system resources such as memory, CPU, and disk space. This limits the number of virtual machines that can run on a single host machine; running lots of virtual machines on a single host requires the use of expensive hosts with lots of CPU and memory.
Scaling Up vs. Scaling Out
Scaling up, also referred to as vertical scaling, means adding more resources to a machine. In most cases, this refers to adding more RAM. This is the less-preferred option in cloud environments as it is usually more expensive, and the demand could outpace the capacity before the new machine has been provisioned. Scaling out, also referred to as horizontal scaling, means to add more instances of the machines to an environment. This is the preferred scaling mechanism in cloud environments.
As we have seen, virtual machines are not ideal for scenarios where new instances need to be spun up quickly.
The next idea that comes to mind is why not just build a process on one of the virtual machines in the existing computer cluster? (A cluster is a group of VMs.) Processes start fast, dynamically allocate resources such as RAM, and are efficient at sharing these, and so it looks like a good fit. The downside with processes is that they are not well-isolated from the rest of the environment, and can quickly result in noisy neighbor situations, potentially compromising the entire virtual machine if the code was not written well.
Noisy Neighbor
The noisy neighbor problem describes a situation where one application takes up or blocks much of the resources that are shared amongst other applications on the same infrastructure. This negatively affects the execution of other processes and applications.
Based on what we know about containers, they seem to be the ideal choice for this scenario. We can spin up a background-processing task quickly, run it isolated, and scale it out quickly.
We can also see the difference between running the rating service in a VM and running it in a container by looking at the figures following. Figure 2.1 shows the high-level topology for a machine (Host OS) hosting two virtual machines (Guest OS) with applications running on virtual machines. The box “Rating Service” represents our rating service on a virtual machine. As we can see, it shares resources with application App on the same virtual machine. If there is a problem with the background task, it can jeopardize the entire machine.
Figure 2.2 shows the rating service running in a container. The container encapsulates everything that is needed for the background task including all libraries, dependencies, and files. It runs as an isolated user process on the same Host OS, sharing the same kernel as other containers. If there is a problem with the rating service it would have no impact on the other applications running in containers as they are isolated from each other.
We used the example of the background-processing task to illustrate how to think about virtual machines vs. containers and processes, but there are other scenarios where containers can be a good fit.
Containers are a great choice in scenarios that require reactive security. As containers are isolated units, the attack space is limited, and due to the speedy boot and shutdown of containers, we can kill them and replace them quickly.
Reactive Security
Reactive security refers to actions that are taken after discovering that some systems have been compromised by a malicious program or script.
As mentioned previously, by using containers we make our applications portable. The very same application container can run on a laptop, a physical or hypervisor server, or in a cloud environment. In particular, dev-test and DevOps benefit hugely from this kind of portability. Chapter 6 covers DevOps practices in detail.
Besides dev-test, high density and microservices scenarios benefit the most from containers, and this is what we will learn in this book.