Before diving into the main topics, let’s learn a bit about the technologies that form the foundation of these Cloud Native Technologies.
[Cloud Native Technology – Cloud native is a strategy for developing and deploying applications that makes use of the benefits of the cloud computing delivery paradigm.]
Virtualization
Virtualization is the process of utilizing specialized software to construct virtual machines [or containers] on a real machine. It is the construction of a software-based (virtual) version of the hardware, storage, server, or applications.
Virtual Machines (VM) and Containers are two technologies that achieve virtualization in distinct ways. First, what makes a virtual machine a virtual machine? – VM is essentially a computer built on software. They operate similarly to a real computer, with an operating system and applications. They are distinct from one another. On a hypervisor, many VMs may run. The hypervisor handles the server resources given to the virtual machines. VMs are Hardware level virtualization. [Happens at the Hardware Level]
A Virtual Machine is called Guest.
- We can construct and execute as many VMs as the CPU, RAM, and other resources of the Host [Physical Machine] will allow. RAM is usually always the bottleneck. All virtual machines share the same resources as the host, yet each virtual machine operates independently.
- A virtual machine is little more than a file on a hard disk. A VM appears and behaves identically like a real machine to the user.
- Not only may a VM be set to utilize a different operating system than its host, but also a different CPU, Storage Device, or NIC.
Hypervisor
Hypervisors are the enabling technology for virtualization. A hypervisor is a software, firmware, or hardware component that builds and runs virtual computers. They pool physical server resources and allocate them to virtual environments. Hypervisors are –
- Key to enabling virtualization
- Creates a virtualization layer
- Acts as a platform for the VMs to be created on
- Manages to share physical resources in the VMs
[Physical Machines – Computers; CPU, Memory, HDD, Network Connection enabled. In the context of Virtualization, Physical Computers are called Host.]
There are two types of hypervisors –
- Type 1 Hypervisor or Bare Metal: It is immediately installed on the physical server. A system that can be placed on computer hardware that operates autonomously. These types of hypervisors are commonly utilized in organizations. It reduces latency and is more secure than competing hypervisors. Example – VMWare ESXi Server, MS Hyper-V, Open Source KVM.
- Type 2 Hypervisor or Hosted: It is installed as software on top of an Operating System on a physical system. Primarily utilized for user virtualization. Example – VMWare Workstation, Virtualbox, etc.
Consider a scenario in which a developer desires to deploy an Application for usage by end users.
In this Example Demonstration, a Type 2 Hypervisor will be considered. On the Physical Hardware resides the Host Operating System, which contains the Hypervisor. Virtual machines may be created using VMWare Workstation, Virtualbox, or any other Hypervisor. This hypervisor assists in launching virtual machines and managing the shared pool of resources.
The application must now be installed on a Linux virtual machine. This Linux VM includes the OS, Libraries, and Binaries required to execute the Application that was developed locally.
As the program was constructed on the local machine, there may be many dependencies, such as a library loaded by the application that is not present on the Linux virtual machines. Things may function OK on the local machine, but they frequently malfunction in production. This hinders the implementation of Agile DevOps and CI/CD.
Alternatively, if we want to scale the program for a large number of users, we may require a new virtual machine with more resources. In this situation, we can observe that the usage of the operating system is redundant. These also consume a substantial amount of hardware resources, causing hardware bottlenecks.
To counter these drawbacks, the containerization concept has emerged.
Containerization
Containerization is a type of virtualization in which programs operate in segregated user areas known as containers while utilizing a common operating system (OS). It uses the concept of cgroup of Linux kernel.
[cgroup – Linux kernel feature that restricts, accounts for, and isolates the resource use of a group of processes.]
Containerization is sometimes referred to as OS Level Virtualization since it occurs at the OS level. Virtual machines are Hardware/Machine Virtualization. Containerization is isolation at the process level.
Kernel allows hardware and software to communicate. Two components of the kernel are used for containerization:
- namespaces – Permitting customization and the appearance that each container instance has its own operating system.
- cgroup – monitoring and measuring the available resources. Limiting controls; restricted access to resources.
Now returning to the scenario described in the context of hypervisors –
In the case of containers, a few preliminary procedures must be completed before virtualization can begin.
The container itself is described by a Manifest. This document displays the contents and loading order of a container. Docker refers to this file as Dockerfile, while Cloud Foundry refers to it as Manifest YAML.
The Image itself is formed from the manifest. This file is used to construct containers and contains instructions on how to do so.
The actual Container is generated from the image. A container is an executable portable package that contains apps and their dependencies. It includes all runtimes, libraries, and binaries required to operate the program.
As the Guest OS is not necessary, it is immediately apparent that fewer resources are being utilized. There is a runtime engine responsible for running containers. In this instance, the resources are assigned dynamically.
The last drawbacks were dependence and scalability. As the containers are built with all dependencies included and the runtime engine executes the containers, Agile DevOps and CI/CD are effectively ensured. As there is no dependence on the Guest Operating System, the program utilizes few resources, which reduces the likelihood of hardware bottlenecks. Containers can share base OS too.
Containers pool together computational resources. Through the runtime engine, they remain sufficiently separated to avoid conflict. Containers do not execute an operating system in its entirety.
Containerization divides programs into their own containers, where they share resources but communicate independently with the operating system. Container characteristics include –
- Highly portable. The application simply has to be written once for many devices.
- Utilizes far fewer resources per container than virtual machines.
- Enables setting up a complicated environment in a few straightforward steps.
What if we needed to add additional details to the application? Suppose the program has additional dependencies on external resources. Our initial program calls the newly created application, which contacts the third party and retrieves the resource from there, and then utilizes it.
In the case of the VMs, we must either re-create all the VMs with a New Application chunk or delete a VM to make way for a New VM containing the New Application and connecting with other VMs.
Contrarily, containers are more convenient. Simply create a container for the new application and execute it with the same runtime engine. The new container is dynamically assigned resources, and it is easy for other containers to connect with it. This method uses far fewer resources than virtual machines.
This chapter outlines the fundamentals of Virtualization, Hypervisors, and Containers. In Chapter 2: Docker & Abusing Docker Registry, we will examine what Docker is, the Docker Architecture, the Docker Registry, and Abusing Docker Registry Misconfigurations.
Please reach out to me if you have any suggestions.