Microsoft, Google, Amazon and everybody else seems to have jumped on this bandwagon in the last year or so, but why is everybody so excited about this stuff?
To understand why containers are such a big deal, let’s think about physical containers for a moment. The modern shipping industry only works as well as it does because we have standardized on a small set of shipping container sizes. Before the advent of this standard, shipping anything in bulk was a complicated, laborious process. Imagine what a hassle it would be to move some open pallet with smartphones off a ship and onto a truck, for example. Instead of ships that specialize in bringing smartphones from Asia, we can just put them all into containers and know that those will fit on every container ship.
The promise behind software containers is essentially the same. Instead of shipping around a full operating system and your software (and maybe the software that your software depends on), you simply pack your code and its dependencies into a container that can then run anywhere — and because they are usually pretty small, you can pack lots of containers onto a single computer.
In the context of talking about shipping containers (and to take that metaphor to its absurd end), that’s akin to having a big container ship with lots of little pools that all feature their own small specialized container ship.
Containers work very differently. Because they only contain the application and the libraries, frameworks, etc. they depend on, you can put lots of them on a single host operating system. The only operating system on the server is that one host operating system and the containers talk directly to it. That keeps the containers small and the overhead extremely low.
What is Container?
Containers are a method of operating system virtualization that allow you to run an application and its dependencies in resource-isolated processes. Containers allow you to easily package an application’s code, configurations, and dependencies into easy to use building blocks that deliver environmental consistency, operational efficiency, developer productivity, and version control. Containers can help ensure that applications deploy quickly, reliably, and consistently regardless of deployment environment.
Instead of virtualizing the hardware stack as with the virtual machines approach, containers virtualize at the operating system level, with multiple containers running atop the OS kernel directly. This means that containers are far more lightweight: they share the OS kernel, start much faster, and use a fraction of the memory compared to booting an entire OS.
What other benefits do containers offer?
A container may be only tens of megabytes in size, whereas a virtual machine with its own entire operating system may be several gigabytes in size. Because of this, a single server can host far more containers than virtual machines.
Another major benefit is that virtual machines may take several minutes to boot up their operating systems and begin running the applications they host, while containerized applications can be started almost instantly. That means containers can be instantiated in a “just in time” fashion when they are needed and can disappear when they are no longer required, freeing up resources on their hosts.
A third benefit is that containerization allows for greater modularity. Rather than run an entire complex application inside a single container, the application can be split in to modules (such as the database, the application front end, and so on). This is the so-called microservices approach. Applications built in this way are easier to manage because each module is relatively simple, and changes can be made to modules without having to rebuild the entire application. Because containers are so lightweight, individual modules (or microservices) can be instantiated only when they are needed and are available almost immediately.
Container Use Cases
Distributed Applications and Microservices
You can use containers to create distributed applications by breaking apart your application into independent tasks or processes (e.g., microservices). For
example, you can have separate containers for your webserver, application server, message queue, and backend workers. Containers are ideal for running single tasks or processes, so you can use containers as the base unit for a task when scaling up and scaling down. Each component of your application can be made from different container images.
You can use containers for batch and ETL jobs by packaging the job into a container and deploying it into a shared cluster. You can run different versions of the same job or multiple jobs on the same cluster or even the same instance since containers are isolated. You can also share the cluster capacity with other processes such as applications and take advantage of fluctuations in the cluster load. You can start jobs quickly and grow jobs dynamically in response to demand, improving resource utilization.
Continuous Integration and Continuous Deployment
You can use containers for continuous integration and deployment because Docker provides a system for image versioning. You can setup your build process to pull your code from a repository, build it, package it into a Docker image, and push the newly created image into an image repository. You can then have your deployment process pull the new image from your repository, test the application, and deploy to your production servers. You can avoid having an application that works on your development environment but fails in production because the Docker daemon is the same across your development, staging, and production machines.