Containers Vs VMs

Containers and virtual machines provide resource isolation and allocation but differ in their virtualization approach. While virtual machines virtualize the entire hardware layer, containers virtualize the operating system level, making them more lightweight and efficient. Let's have a dipper dive.

Typically, a developer aims to run an application quickly without hitches. However, challenges are encountered with portability and efficiency, when the application needs to work consistently on multiple hardware and platforms, such as the laptop, VMs, data centers, public and private clouds, basically from the development environment to production.

In computing, virtualization is a technology that is applied for sharing the capabilities of physical computers by splitting the resources among OSs. i.e. creates an abstraction layer over physical compute hardware, enabling the division of a single computer's hardware resources such as processors, memory, and storage into multiple virtual machines (virtual environments that simulate a physical computer in software form). Each VM runs its operating system (OS) and behaves like an independent computer, even though it is running on just a portion of the actual underlying computer hardware.

What are virtual machines?

With the help of hypervisor technology, virtualization is made possible (creates a virtual machine) which allows for more efficient use of physical hardware. This software layer is placed on a physical computer (bare metal server) that allows the physical computer to separate its operating system and applications from its hardware. These virtual machines can run their operating systems and applications independently while still sharing the original resources (memory, RAM, storage, and so on) from the server, which the hypervisor manages. In essence, the hypervisor acts like a traffic cop, allocating resources to virtual machines and ensuring they don’t disrupt each other. In addition, most modern CPUs also support nested virtualization, a feature that enables VMs to be created inside another VM.

The hypervisor (Type-1) can run directly on the physical host machine's hardware (usually bare metals), replacing the OS, a kernel-based virtual machine (KV), AWS Nitro, Microsoft Hyper-V, VMware ESXi, etc. can be used to achieve this and they are mostly secure, provide low latency while the hypervisor (Type-2) can run as an application within a host's OS and usually target single-user desktop or notebook platforms eg. VirtualBox, VMware Player, VMware Workstation. With a Type 2 hypervisor, you manually create a VM and install a guest OS inside, which is mostly used for end-user virtualization. You can use the hypervisor to allocate physical resources to your VM, manually setting the number of processor cores and memory it can use.

What are containers?

Containers offer a more lightweight and agile virtualization approach compared to traditional virtual machines. By eliminating the need for a hypervisor, containers enable faster resource provisioning and quicker application deployment. As an application-level abstraction, containers bundle code and dependencies together. Multiple containers can share the host operating system kernel, running as isolated processes in user space. This efficiency leads to smaller container images (often measured in megabytes), allowing for more applications to be deployed per host and reducing the need for numerous virtual machines and operating systems.

Containers Vs VMs: What are the differences?

Traditional Virtualization: VMs and Hypervisors

In traditional virtualization, a hypervisor acts as a middleman, abstracting the physical hardware resources of a server. Each virtual machine (VM) running on the hypervisor emulates a complete physical server, including a guest operating system (OS), virtual hardware, and the application with its associated libraries and dependencies. This setup allows multiple VMs with different operating systems to coexist on a single physical server.

Virtualization provides machine-level isolation, while containers offer process-level isolation. Although containers share the same host operating system kernel, they operate within their own isolated environments. In virtualization, the hypervisor manages resources, whereas, in containers, the Linux kernel leverages namespaces and cgroups to create the illusion of process isolation.

• Namespaces: Namespaces encapsulate global system resources like networks and process IDs, making them appear isolated to processes within the namespace.
• cgroups: Control groups provide hierarchical organization and resource allocation for processes, ensuring controlled and configurable distribution of system resources.

Unlike VMs, containers virtualize the operating system level rather than the entire hardware. This means that each container only contains the application, its libraries, and dependencies. Containers are significantly smaller, faster, and more portable than VMs because they don't require a full guest OS for each instance. They can leverage the features and resources of the host OS directly.

Resource Utilization and Microservices

Both VMs and containers provide benefits in terms of improving the CPU and memory utilization of physical machines. However, containers offer an even more granular level of control. They enable microservice architectures, where individual application components can be deployed and scaled independently. This is a significant advantage over monolithic applications, where scaling the entire application is necessary even if only a single component is experiencing high load.

In conclusion, by combining the flexibility of traditional hypervisors with the portability of containers, we can create a hybrid virtualization environment. The evolution of technologies like kubeVirt and advancements in Kubernetes and OpenShift demonstrates the growing maturity of virtual machines and containers. Rather than viewing them as competing technologies, we can leverage both to address various use cases, tailoring our approach based on specific requirements.