Containerization: How does it work and what are the advantages?

Hey everyone, I’m excited to be back with yet another lightboarding video. This time we’re going to be taking a close look at containers and containerization.

I’ll be using the example of a Node.js application that I want to push into production, and we’ll be using two different form factors—virtual machines (VMs) and containers—to explain the advantages of containerization.

The main points I wanted to hit in this video are the portability of containers, the advantages they offer around scalability, and the increasingly agile DevOps processes that containers facilitate.

I hope you enjoy the video!

Learn more about Kubernetes and containers

Video Transcript

What is containerization?

Hi everyone, my name is Sai Vennam, and I’m a developer advocate with IBM. Today, I want to talk about containerization.

The history of containerization technology

Whenever I mention containers, most people tend to default to something like Docker or even Kubernetes these days, but container technology has actually been around for quite some time.

It was actually back in 2008 that the Linux kernel introduced C-groups, or control groups, that basically paved the way for all the different container technologies we see today. So that includes Docker but also things like Cloud Foundry as well as Rocket and other container runtimes out there.

An example to illustrate the advantages of containerization

Let’s get started with an example. We’ll say that I’m a developer, and I’ve created a Node.js application, and I want to push it into production. We’ll take two different form factors to kind of explain the advantages of containerization.

Let’s say that, first, we’ll talk about VMs and then we’ll talk about containers.

Virtual machines (VMs) and the Node.js application

So, first things first, let’s introduce some of the things that we’ve got here. So, we’ve got the hardware itself, which is the big box. We’ve got the guest, or rather the host operating system, as well as a hypervisor. The hypervisor is actually what allows us to spin up VMs.

Already we’ve—and let’s take a look at the shared pool of resources—with the host OS and hypervisor, we can assume that some of these resources have already been consumed.

Spinning up Linux VMs

Next, let’s go ahead and take this .js application and push it in. And to do that, I need a Linux VM. So, let’s go ahead and sketch out that Linux VM. And in this VM, there’s a few things to note here. So, we’ve got another operating system in addition to the host OS—it’s going to be the guest OS. As well as some binaries and libraries.

So that’s one of the things about Linux VMs—even though we’re working with the really lightweight application, to create that Linux VM, we have to put that guest OS in there and a set of binaries and libraries. And so, that really bloats it out. In fact, you know, I think the smallest Node.js that I’ve seen out there is 400+ megabytes. Whereas the Node.js runtime app itself would be under 15.

So, we’ve got that, and we go ahead and let’s push that .js application into it, and just by doing that alone, we’re gonna consume a set of resources.

Scaling out the VM

Next, let’s think about scaling this out, right? So, we’ll create two additional copies of it. And you’ll notice that even though it’s the exact same application, we have to use and deploy that separate guest OS and libraries every time. And so, we’ll do that three times.

By doing that, essentially, we can assume that for this particular hardware, we’ve consumed all of the resources.

Containers and Agile DevOps

There’s another thing that I haven’t mentioned here—this .js application, I developed on my MacBook. So, when I pushed it into production to get it going in the VM, I noticed that there were some issues and incompatibilities. This is the kind of foundation for a big “he said, she said” issue, where things might be working on your local machine and work great, but when you try to push it into production, things start to break. This really gets in the way of doing Agile DevOps and continuous integration and delivery.

A three-step process for creating containers

That’s solved when you use something like containers. There’s a three-step process when kind of doing anything container-related and pushing or creating containers. And, it almost always starts with, first, some sort of a manifest. So, something that describes the container itself. So, in the Docker world, this would be something like a Dockerfile, and in Cloud Foundry, this would be a manifest yaml.

Next, what you’ll do is create the actual image itself. So, for the image—you know, again, if you’re working with something like Docker, that could be a docker image; if you’re working with Rocket, it would be an ACI or application container image. So, regardless of the different containerization technologies, this process stays the same.

The last thing you end up with is an actual container itself, that contains all of the runtimes and libraries and binaries needed to run an application.

Components of a container

That application runs on a very similar setup to the VMs, but what we’ve got on this side is, again, a host operating system. The difference here is, instead of a hypervisor, we’re going to have something like a runtime engine. So, if you’re using Docker, this would be the Docker Engine, and, you know, different containerization technologies would have a different engine. Regardless, it’s something that runs those containers.

Again, we’ve got this shared pool of resources; so we can assume that that alone consumes some set of resources.

Containerizing the technology

Next, let’s think about actually containerizing this technology. So we talked about the three-step process—we create a Dockerfile, we build out the image, we push it to a registry, and we have our container—and we can start pushing this out as containers.

The great thing is, these going to be much more lightweight. So, deploying out multiple containers—since you don’t have to worry about a guest OS this time, you really just have the libraries as well as the application itself.

So, we scale that out three times, and because we don’t have to duplicate all of those operating system dependencies and create bloated VMs, we actually will use less resources. So, let’s use a different color here. And, scaling that out three times—we still have a good amount of resources left.

Taking advantage of a third-party service

Next, let’s say that my coworker decides, hey for this .js application, let’s take advantage of a third party—you know, let’s say a cognitive API to do something like image recognition. So, let’s say that we’ve got our third-party service, and we want to access that using maybe a Python application.

So, he’s created that service that accesses the third-party APIs, and with our Node.js application, we want to access that Python app to then access that service.

If we wanted to do this in VMs, I’m really tempted to basically create a VM out of both the .js application and the Python application because, essentially, that would allow me to continue to use the VMs that I have.

But that’s not truly cloud-native, right? Because if I wanted to scale out the .js but not the Python app, I wouldn’t be able to if they’re running in the same VM. So to do it in a truly cloud-native way, essentially, I would have to free up some of these resources—basically, get rid of one of these VMs, and then deploy the Python application in it instead. And, you know, that’s not ideal.

The container-based approach

But with the container-based approach, what we can do is simply say, since we’re modular, we can say—okay, just deploy one copy of the Python application. So we’ll go ahead and do that in a different color here. And that consumes a little bit more resources.

Then, you know, with those remaining resources, the great thing about container technology, that actually becomes shared between all the processes running. In fact, another advantage—if these container processes aren’t actually utilizing the CPU or memory, all of those shared resources become accessible for the other containers running within that hardware.

Taking advantage of cloud-native-based architectures with containers

So, with container-based technology, we can truly take advantage of cloud-native-based architectures. So, we talked about things like portability of the containers; talked about how it’s easier to scale them out; and then, overall, with this three-step process in the way we push containers, it allows for more Agile DevOps and continuous integration and delivery.


More from Cloud

IBM Cloud inactive identities: Ideas for automated processing

4 min read - Regular cleanup is part of all account administration and security best practices, not just for cloud environments. In our blog post on identifying inactive identities, we looked at the APIs offered by IBM Cloud Identity and Access Management (IAM) and how to utilize them to obtain details on IAM identities and API keys. Some readers provided feedback and asked on how to proceed and act on identified inactive identities. In response, we are going lay out possible steps to take.…

IBM Cloud VMware as a Service introduces multitenant as a new, cost-efficient consumption model

4 min read - Businesses often struggle with ongoing operational needs like monitoring, patching and maintenance of their VMware infrastructure or the added concerns over capacity management. At the same time, cost efficiency and control are very important. Not all workloads have identical needs and different business applications have variable requirements. For example, production applications and regulated workloads may require strong isolation, but development/testing, training environments, disaster recovery sites or other applications may have lower availability requirements or they can be ephemeral in nature,…

IBM accelerates enterprise AI for clients with new capabilities on IBM Z

5 min read - Today, we are excited to unveil a new suite of AI offerings for IBM Z that are designed to help clients improve business outcomes by speeding the implementation of enterprise AI on IBM Z across a wide variety of use cases and industries. We are bringing artificial intelligence (AI) to emerging use cases that our clients (like Swiss insurance provider La Mobilière) have begun exploring, such as enhancing the accuracy of insurance policy recommendations, increasing the accuracy and timeliness of…

IBM NS1 Connect: How IBM is delivering network connectivity with premium DNS offerings

4 min read - For most enterprises, how their users access applications and data is an essential part of doing business, and how they service those application and data responses has a direct correlation to revenue generation.    According to We Are Social’s Digital 2023 Global Overview Report, there are 5.19 billion people around the world using the internet in 2023. There’s an imperative need for businesses to trust their networks to deliver meaningful content to address customer needs.  So how responsive is the…