Whether you want to use Containers or Virtual Machines (VMs) depends on what you are trying to accomplish. As to which is better --- Container or VM, it's a complex question that needs a multifaceted answer.
Virtualization creates an environment where workloads run on a platform that is separated from its underlying, foundation hardware by a layer of abstraction. The entity that renders this layer is the hypervisor, for example ESXi from VMware. This abstraction allows servers to split resources into virtualized machines (VMs) that can run either the same operating system on multiple VMs or different operating systems across them, or more commonly a mix of the two.
Container technology offers an alternative to virtualization, in which one single operating system on a hardware machine will run many different applications from the cloud. An ideal way of understanding containers versus VMs is that while VMs run various or multiple operating system instances on one compute node, container technique provides the platform to virtualize the operating system itself.
For those of you who might be thinking that container technology is a new phenomenon, the opposite is true. Containers were introduced more than a decade ago but have been gaining traction only after technologies like Docker and Kubernetes appeared on the technology horizon.
With VMs, a software component layer called a hypervisor acts as the glue, the playground between the VM and the underlying hardware, thereby providing the requisite level of abstraction. The hypervisor, VMware's ESXi for example, owns the responsibility of riding the several virtual machines created on it. While VMware ESXi is the most well known hypervisor, there are others like Microsoft Hyper-V, Citrix Xen and KVM out there in the market. Modern technology has evolved to a point where processors interact directly with hypervisors, providing them with paths for lining up instructions from the VMs completely invisible or transparent to the applications running inside these VMs. Advanced network virtualization models like VMware NSX have made things even better from a functional perspective.
The scalability or scope of a VM server workload or workloads is achieved on lines similar to how it is done on bare metal servers. With a Web server or a database application, the programs and processes responsible for delivering services are distributed amongst multiple machines or VMs. Load balancers are configured on the front end for these VMs to direct and distribute traffic to ensure no specific server/VM is overloaded or underutilized. Automated procedures within VM builds make such load balancing processes react to changes in traffic patterns every few moments.
With VMs, a software component layer called a hypervisor acts as the glue, the playground between the VM and the underlying hardware, thereby providing the requisite level of abstraction. The hypervisor, VMware's ESXi for example, owns the responsibility of riding the several virtual machines created on it. While VMware ESXi is the most well known hypervisor, there are others like Microsoft Hyper-V, Citrix Xen and KVM out there in the market. Modern technology has evolved to a point where processors interact directly with hypervisors, providing them with paths for lining up instructions from the VMs completely invisible or transparent to the applications running inside these VMs. Advanced network virtualization models like VMware NSX have made things even better from a functional perspective.
The scalability or scope of a VM server workload or workloads is achieved on lines similar to how it is done on bare metal servers. With a Web server or a database application, the programs and processes responsible for delivering services are distributed amongst multiple machines or VMs. Load balancers are configured on the front end for these VMs to direct and distribute traffic to ensure no specific server/VM is overloaded or underutilized. Automated procedures within VM builds make such load balancing processes react to changes in traffic patterns every few moments.
The concept of virtualization was initially developed to segregate namespaces in a Linux operating system for security purposes. The first Linux environments produced partitions (often referred to as "jails") within which applications of unproven security and authenticity could be run without risk or compromise to the kernel functionality. The kernel was still in charge of the processing and running the show while a layer of abstraction was introduced between the kernel and the workloads.
Once improvements were made on these partitions to make them lightweight and more productive, the next great idea was to make them portable across containers and machines.
Workloads within a container such as Docker are virtualized. However, in Docker there is no layer like a hypervisor. On the contrary, the Linux kernel is associated with a daemon process continuously running that establishes and maintains the segregation or separation/isolation between containers while getting their workloads to communicate with the kernel. Today's containers include minimalized operating systems such as the open source CoreOS as well as VMware's Photon OS which diligently perform the task of maintaining essential heartbeat functionality/services for the programs and applications they own and do not provide a full fledged processor landscape.
Scalability of workloads in containers works completely different when compared to VM workloads. Current day containers include the most basic and essential services their operations require but one of them is a Web server, typically nginx, that doubles up as a load balancer. Generally, sophisticated container systems like Google's Kubernetes and Mesosphere's Marathon are capable of orchestrating and discovering when the number of containers needs to expand, can create or replicate additional containers on the fly, and eliminate them if and when they are not needed.
The most important characteristic that differentiates a container from a VM is the container's transient, short lived nature. Generally, multiple instances of a container coexist. Containers that fail can be discarded and replaced without noticeable disruption or consequence on service availability. In the most demanding environments, where everything is done to ensure business continuity and system uptime, staging and or new developmental instances of containers work in conjunction with proven, older versions. Upon failure, the newer instances can be rolled back and withdrawn/replaced. This shift in trend, and the drastic improvements in managing data centers, cloud and applications have evinced key interest in major players in the telecommunication field to explore and express interest in Docker and its related technologies, of late.
No comments:
Post a Comment