Why VMware's Kubernetes Ambitions Depend on MinIO

Perhaps the biggest takeaway from VMworld was the “all in” bet that VMware is making on Kubernetes. VMware wasn’t shy about its ambition, with CEO Pat Gelsinger stating that “We will be the leading enabler of Kubernetes.”

This reflects the reality of the market. Kubernetes has become the industry standard. Furthermore, Kubernetes has grown into more than just orchestration, it is a platform for distributed systems - connecting developers and operators across infrastructure from the public cloud, private cloud and the edge.  

Storage is a massive part of this overall bet and VMware needs MinIO to deliver against their ambitions. MinIO brings cloud-native applications to the VMware ecosystem, allowing them to be containerized and orchestrated and making VMware look more like AWS.

Kubernetes demands S3.

That makes object storage a critical infrastructure component in VMware’s ambitions. Consider the following:

VMware already has many of the components that define the public cloud experience (using AWS as the leader). VSphere provides Virtual Machines, just like EC2, and both ECS and PKS will orchestrate container microservices. Where EBS provides block storage, so does vSAN. VMware is missing an cloud-native S3 object store. While there are forklifted bolt-on versions of S3, none of them are cloud native. This is pretty important, considering object storage is perhaps the most significant component in the AWS tech stack.

That is where MinIO comes in. MinIO is built from scratch to be cloud-native, high performance, S3 compatible object storage. It only does one thing - serve objects and aims to do that better - and faster than anyone else. As a result, MinIO has established itself as the standard in the private cloud. Adopting it as the poster child for VMware deployments made sense. And that is exactly what VMware did - detailing that approach in this blog post:

You will all recognize the MinIO stork in this picture as the foundation of Kubernetes Pods. The stork is a little out of date, but we won’t penalize VMware for listing us as the default for containerized storage managed by Kubernetes - which is exactly what they do in this diagram.

There is a lot in this diagram but underpinning it is a battle between AWS and VMware that is shaping the tech world. Essentially, there are many business critical applications that are running on VMware in the enterprise. AWS wants to take those applications into the cloud. VMware, on the other hand, wants to repatriate cloud native applications back onto VSphere.

The combination of microservices, Kubernetes and MinIO/S3 object storage are the foundational building blocks of the modern cloud. By bringing those technologies to VMware you give modern cloud applications a home in the VMware ecosystem. Failure to do so results in those valuable applications moving to AWS as they eventually adopt a microservices orientation.

It is not just AWS though - it is any cloud. Multi-cloud is the new reality and here again, the adoption of cloud-native technologies ensures that VMware can address their customer’s needs across the cloud-sphere.

It is not just a defensive move by VMware. VMware has designs on winning back some of the large analytic workloads that migrated to the cloud over the past number of years. Legacy, bolted-on, archival object storage won’t do the trick for VMware. They need modern, high-performance object storage - again, why they call out MinIO in their reference architecture. Object storage from legacy, archival-oriented appliance vendors isn't container friendly and doesn't help VMware advance their goals. Only with performant, Kubernetes friendly object storage will VMware be able to attract heavy analytics applications back to the data center.

Feel free to kick the tires for yourself either by following the instructions in the VMware post, looking at our Pivotal Tile or by pulling our Kubernetes download.