Whether you aspire to become a seasoned DevOps engineer or simply enjoy programming as a hobby, understanding containers offers numerous advantages. Containers can be considered as a foundation to move on to Docker, Kubernetes, and other cloud-native technologies. In this blog, I provide a concise introduction to containerization. This is the first in the series, "This is Docker"

Why Do We Need Containers?

In the early days, technology was not sophisticated enough to run multiple applications on the same server. Simultaneously, reliable measurements to understand application requirements were lacking. To avoid underpowered servers, every time a company had a new application, they would simply purchase a new server. This soon resulted in servers running at only 5-10% of their potential. What a waste!

VMware enters the chat! VMware offered a solution to run multiple applications on a single server, this naturally resulted in companies more value out of their investment in servers. However, VMs had their own challenges. Each VM had its own OS, consuming CPU, RAM, and storage that could otherwise be used by the applications running on them. Additionally, every OS required patching, maintenance, and licensing. VMs were also slow because each VM had to boot an entire operating system from scratch before it can finally start!

Enter Containers! For a long time, companies like Google used containers to address the shortcomings of VMs. Docker brought containers to the masses. The most significant difference between containers and VMs is that containers don't need their own OS. All containers on a local machine run on a single OS, which is the OS of the local machine. This is a major upgrade. This feature saves on OS-related costs, CPU, RAM, storage, and licensing expenses. Containers are also lightning-fast to start and highly portable.

OS Tax

Each VM has its virtual CPU, virtual RAM, virtual disks, etc. So to claim these it needs its own OS. However, each OS comes with its baggage and overheads. For example, every OS consumes CPU and RAM and needs their licensing and people to patch and monitor them. We refer to all this overhead as OS tax and VM tax.

In the container model, a single OS runs on a shared host. So only one OS is consuming CPU and RAM and storage, a single OS that needs licensing so all in all a single OS tax bill.

What Are Containers?

Now that we understand containers are pretty cool, let's define them.

Think of transportation, for example.

Individual goods that need to be transported are grouped and shipped together. These goods are protected by the container, and using containers allows us to make efficient use of space on ships, aeroplanes, vans, etc. This reduces transportation costs and makes tracking goods easier because we can track the container, effectively monitoring all the goods. There are many more advantages to this approach.

Similarly, we use containers to package source code and dependencies. These containers isolate their contents from other containers and the processes running on the local machine.

A container is a sandboxed process running on a host machine that is isolated from all other processes running on that host machine. This isolation leverages Kernel Namespaces and cgroups.

Kernel namespaces and control groups (cgroups) are Linux technologies used for containerization. We will discuss them in detail in the upcoming blogs.

• Containers are lightweight and contain everything needed to run the application.

• The isolation and security allow you to run multiple containers simultaneously on a given host.

• You can share containers, ensuring everyone in the team has a container that works the same way.

Containerization vs. Virtualization

We've already discussed that the main difference between containers and VMs is that containers don't need their own OS. All containers running on a single host share the same OS, which is the host's OS.

Let's delve a little deeper.

Imagine you have four applications, and you decide to run them on your server.

Case 1: You Have Used Virtualization

What VM does is that the hypervisor claims all physical resources, such as CPU, RAM, storage, network cards, and virtualizes them. It then packages them into a software construct called a Virtual Machine. We install our operating systems and applications on these VMs. So, the above scenario would look like this.

Case 2: You Have Used Containerization

In this container model, the OS claims all hardware resources. We install a container engine, such as Docker. The container engine then virtualizes OS resources, such as process trees, filesystems, network stacks, etc., and packages them into virtual operating systems called Containers. Each container functions like an OS. Inside each container, we run an application. The same scenario would look like this.

In short, VMs virtualize hardware, while containers virtualize the OS.

Benefits of Using Containers in Development and Deployment

1. Portability

   • Containers are lightweight and contain everything needed to run the application.

   • The isolation and security allow you to run multiple containers simultaneously on a given host.

   • You can share containers, ensuring everyone has a container that works the same way.

2. Version Control

   • Containers, as discussed, provide a way to package applications and dependencies into a single unit that can be easily versioned.

   • Containers are immutable. When we say "updating a container," we mean deleting the existing container and creating a new one. This makes it easy to track changes.

3. Resource Efficiency

   • Containers are lightweight and incur less overhead on the machine.

   • Since containers share a single OS (unlike VMs), and there's less OS tax, system resources are better utilized.

4. DevOps Integration

   • DevOps is a set of practices aimed at bringing together development, operations, and testing teams to shorten the software development lifecycle and improve software quality. Containers are a key enabler of DevOps as they make it easier to automate the deployment of applications and provide a consistent environment for development, testing, and production. A consistent environment ensures that applications behave the same way across all teams.

Note: I have used ChatGPT for strictly proofreading this blog. You can read the original blog here but expect spelling mistakes and grammatical errors 🤦

This has been a brief introduction to Containers. We will learn how Docker handles containers and how Kubernetes fits into the picture in the upcoming blogs. I hope this has been a useful blog to you. To get updates on this series "This is Docker", subscribe to my newsletter. Thanks for reading 🫡❤️