Pat Gelsinger, CEO of VMware, recently said “Kubernetes is driving the biggest shift in enterprise architecture since Java, virtualization and cloud…”Well, that seems to clarify what you should be worrying about for the next ten years. In this first post of a four-part series, I want to set the stage for Kubernetes by starting with virtualization.
Virtualization in the data center, led by VMware starting in 2001, ushered in a decade of IT re-architecture and the emergence of the software-defined datacenter. Hot on its heels, and exhibiting some of the same philosophy of “do more with less – faster” has been the emergence of cloud computing. Led and dominated by Amazon Web Services, cloud computing has also ushered in Microsoft resurgence with its Azure offering a force to be reckoned with in the new IT landscape. Cloud computing has disrupted data center IT for the past decade, gaining speed in the past few years.
VMware and Amazon rode two technology disruptions, virtualization and cloud computing respectively, to emerge as leading players in IT. Other companies came and went or diminished in their impact to the data center. While the initial impetus for virtualization was gaining access to unused CPU capacity as multicore CPUs became dominant, it was the emergence of the software defined and orchestrated data center that became the fundamental impact of virtualization. Application provisioning was no longer started with deploying a bare metal platform to run the application. Virtualized applications were launched to an available virtualized platform, and load balanced and monitored through a common virtualizing software layer.
Kubernetes is the next wave of technology refining the software defined data center. VMware is redefining itself rapidly through acquisitions and investments to be a leader in what could become the de facto data center orchestrator, called Kubernetes. What is it VMware sees in Kubernetes? What does it help IT do? And how should you be thinking about it for your business?
Kubernetes has emerged as the leading solution for container orchestration. Other container orchestration solutions include Docker Swarm and Mesosphere Marathon, as well as cloud-based container orchestration services. What’s important about these orchestration solutions is they provide a comprehensive management for application containers at scale:
- Provision and deploy containers (that is, containerized applications)
- Load balance across and move containers between nodes (compute hosts)
- Self-heal when a container fails (restart a container, or application instance)
- Advertise services defined by the containers
- Provide for containerized application versioning and upgrade
Kubernetes came out of Google in 2015. Google had used container technology internally for some time. Via Kubernetes, their approach to container orchestration was open sourced and proposed as a common method across private and public clouds. Much of the container discussion today revolves around orchestration, and that means increasingly Kubernetes. Since 2015, Kubernetes has evolved considerably – change is the only constant around Kubernetes. I’ll keep reminding you of that.
For VMware, and Google, Amazon and Microsoft with their cloud-based Kubernetes services, the objective is to win customers transitioning to Kubernetes from bare-metal, but also from VMs over the next decade. Sometimes you have to eat your own in a transition and VMware has signed up to this strategy.
I’m going to continue to explore containers and orchestration over the next three posts, and give you DriveScale’s take on this technology.
But now we must go back to the beginning, and that means we must talk about containers in the following post.