VIRTUALIZATION: The present is virtual, the future should be too.
The history of the data centre is a long drive to efficiency. Bare metal servers waited for I/O to finish before continuing other work, so multi-tasking operating systems were invented to give servers the power to run other tasks while they waited for I/O to complete.
Multi-tasking created demand for more servers, but all too often those machines were tightly coupled to single applications and operating systems and if they weren’t busy, the server was underutilized.
Virtualisation rescued servers from that underutilization and meant organisations could run fewer but bigger physical servers and myriad virtual machines (VMs). Hypervisors could load VMs with different operating systems so that one physical server could run Windows, Unix and Linux environments simultaneously. Each VM was given the resources it needed and everything was rosy - for a while.
Kubernetes is an application like any other. It's better off virtualized. Then came hyperscale services running on millions of servers, a situation that made it critical to extract every last cycle of server power with as little wasted or idle as possible.
VMs didn’t work well at hyperscale. Enter containers and micro-services, which have become the base execution unit for hyperscale services and recently for more mainstream software developed using the same techniques employed by hyperscale operations.
So now we have two kinds of data centres used by businesses and other organisations: VM-centric data centres and containerized data centres. We also have two ways of producing applications.
It’s confusing and complex.
What should we do?
One option is to have public clouds convert to VM-centric operations, but that won’t happen because hyperscale operators’ resource recovery models need containers. VMs as their as the core execution unit is too wasteful of IT resources.
Another option is for the on-premises world to convert to microservices, containerize everything and run like public clouds. But the complexity and expense involved is out of proportion for non-hyperscale operations.
The third choice is to go hybrid, to combine the different on-premises and public cloud worlds under an abstraction layer that presents a unified and coherent environment to run applications.
Brilliant idea. Then the on-premises world could carry on doing what it’s doing; running virtual machines in virtualized servers; and the public clouds could carry on running containers.
One problem; where is this abstraction layer?
It already exists. It’s called virtualization – because a virtualized server can run containers.
What strange magic is this? The tools that manage containers – like Kubernetes – are an application like any other. They’re better off virtualized. Containers themselves share an operating system. Any instance of an OS is better off virtualized.
Further, we don’t need containers to have on-premises-to-public cloud application mobility.
Virtual machines are already mobile. VMware, Microsoft and all the big clouds offer VM migration tools and services.
VMware, which dominates the virtual server market, has relationships that VMs it created run in AWS, Azure, Google Cloud, Oracle Cloud and Alibaba Cloud.
Hyperscale services extracting every last cycle of server power critical Because VMs are already mobile we don’t need to containerise our applications to enjoy multi-way mobility between public clouds and on-premises data centres. And even if you do decide to develop with containers, they need the resilience, security and manageability that virtual machines afford.