In an ongoing effort to streamline infrastructures, maximize server resources, and ensure that applications run smoothly and securely, different approaches have shaken up the traditional server-side architecture—things like the cloud and virtualization. More and more businesses are migrating applications away from traditional IT set-ups in the search of better performance, more efficiency, and more competitive operating costs.
In this mix is containerization, a technology that isn’t new but that’s being used in new ways. It offers a more efficient alternative to virtualization and it’s heavily influencing the future of cloud computing—and the direction of Infrastructure-as-a-service (IaaS) businesses that offer private and public cloud services like Heroku, CloudFoundry, and OpenStack.
The efficiency and cost competition that containerization-as-a-service (CaaS) businesses can offer are driving its adoption—here’s a look at how the technology works, how it’s supporting the DevOps culture, and some of its benefits so you can decide if it’s right for your application.
Containerization: a step beyond virtualization
Virtualization is the decades-old approach to maximizing hardware resources by putting apps into “virtual machines” (VMs) with their own operating systems, which then run independently on top of a server’s operating system. Virtualization in a data center is all about consolidation and cost savings—a virtualized server is able to increase the app-to-machine ratio and host numerous apps at once. Similarly, virtualization has made much of what happens in the cloud environment possible, partitioning up public and private clouds to host numerous applications at once.
If virtualization (i.e., virtual machines) was designed to address consolidation of servers and resources, containerization was designed to solve a more modern problem: application management issues. While similar and with similar benefits, it’s not a replacement for virtualization—it’s complementary to it. Containerization is application-specific, providing apps with dedicated environments to run on, which can in turn be deployed and run anywhere without requiring an entire virtual machine for each app.
Virtualization showed us we didn’t need an entire server for one application; containerization shows us we don’t need an entire operating system for each application.
How does it work?
Containerization essentially virtualizes an operating system so applications can be distributed across a single host without requiring their own virtual machine. It does this by giving an app access to a single operating system kernel, which is the core module of the operating system. All containerized apps running on a single machine will run on the same Linux kernel.
Why use containerization?
The key is to make applications able to run anywhere, on any machine. Containerization makes applications portable by virtualizing at the operating-system level, creating isolated, encapsulated systems that are kernel-based. From there, distributed, containerized apps can be dropped in anywhere and run without dependencies or requiring an entire VM. By including its own operating system, it’s eliminating dependencies.
Aside from the portability aspect, containerization’s other main benefit is that it requires far fewer resources. For instance, you can run numerous containers at once without taking up a lot of space, whereas with virtualization, doing the same can require many more GBs of space. When you’re only dealing with one operating system for all of these containers (i.e., one kernel), you can run far more containers on a host than you could full-blown virtual machines.
Note: At this juncture, containerization is Linux-specific (or alternatively, Ubuntu, which is Linux-based). This is because the technology is founded on Linux containers, which hinge on features of Linux kernels. However, Docker supports integration with Windows (Microsoft Azure).
Here are a few other benefits:
- Sharing a kernel means you can put more applications on a single server. It’s also not its own self-contained environment, like a virtualized environment where an operating system is replicated each time, with all of that associated overhead. Containerization removes that OS layer, instead of sharing the Linux kernel with the host machine and any other containerized apps running on it. That makes the containers much smaller in size, and so you can pack a lot more onto a machine (and run more apps concurrently) than you can virtualized machines.
- Sharing also enables containerized apps to launch faster than a virtual machine. Because they’re running on an operating system kernel that’s already booted up, you’re not waiting on that virtual machine to boot up its own OS—it’s faster and lighter in a container. This saves time—as much as the difference between less than a second vs. several minutes.
- Supports a more unified DevOps culture. Typically, developers handle applications and application frameworks (or ‘runtimes’), while the IT operations side is concerned with the operating system and server. Both have the end goal of high quality software releases, but need to rely on each other when things change during the development cycle—and when it’s time to scale up. Developers want scalability, while operations are focused on application management and efficiency. Containers keep a separation between the two, isolating their processes and helping them to achieve their respective (and common) goals in tandem.
Is containerization the right solution for you?
What apps work best with containerization? Should you add a container to your IT stack? Whether or not your application is a good fit has to do with the application’s specific workload. Your IT manager or developer can help you assess if things like performance, network latency, security, or memory usage will be affected by the container setup vs. having that application run on a virtual machine, or even “bare metal”—just the server alone.
For example, if your application processes transactions as a batch job, it won’t require as much real-time performance or network support and maybe a great fit. However, if it requires more stability to run at a high-performance lever, this is something to consider. The more demanding the app, the fewer layers of abstraction you want between it and the server, and containerization is all about abstraction.
The bottom line is controlling your resources, choosing a scalable solution, and doing what makes sense from a DevOps perspective. A container model won’t be perfect for everything, but depending on the workload, it might be a great fit. For example:
- Containerization enables developers to fully “own” the setup and configuration of their app’s runtime environment. The build pipeline prepares a container, which will then be placed in the various environments (e.g., pre-production environments such as integration testing, load testing, etc. and then on to the production environment) of the deployment pipeline.
- It can simplify the DevOps deployment tool chain, which no longer needs to differ based on the nature of the runtime artifact (e.g., PHP vs JVM, etc.). All runtime differences are encapsulated within the container.
Securing containers
With virtualization, you need to secure the host OS and every OS running on top of it. With a containerization model, you just need to secure that one OS—and the docker engine on top of it (similar to the hypervisor).
There are security aspects to consider, though. If containers share an environment, they have thin layers separating them. Breakthrough one of these layers and you have access to more. Also, a shared kernel is fundamentally less secure than a dedicated kernel.
To tackle security concerns with containerization, some container management systems have created associated encryption and security services, like Docker Secrets. Or, using kernel modules that isolate processes that protect containers. This better manages the way distributed applications access and transmit data.