VMware Project Cascade: The Future of VMware

Download this briefing note as a PDF to share with your team.

VMware’s Project Cascade aims to provide a Kubernetes interface to vSphere that will allow it to serve both the traditional vSphere audience as well as the new cloud-native developer audience that is rapidly gaining momentum and mindshare. This will provide an important migration path for enterprises that have invested substantial resources in VMware-based infrastructure that underpins business-critical workloads, particularly in managing and operating this infrastructure.

A wholesale replacement of this infrastructure to move exclusively to cloud-native techniques like containers and Kubernetes, or public-cloud services is an expensive and risky proposition, and will take most enterprises many years to achieve.

Maintaining two completely different systems that do not interoperate—and therefore duplicating the people, skills, tools, and processes required—is obviously wasteful, but may be perceived as necessary. VMware is looking to provide a compromise that helps enterprises migrate at their own pace without throwing away what already works.

By providing an interface to the new world of Kubernetes, VMware hopes to ensure that developer desires will not force their existing customer base of enterprises to completely abandon them. VMware has determined that it needs something that looks and feels sufficiently like starting from scratch with Kubernetes, but without the operational pain.

If VMware is successful, it will have managed to bring to Kubernetes what it did with virtualisation: a level of cross-industry standardisation that allows everyone else to collaborate on a de facto standard. VMware could end up being the multi-cloud abstraction that works well enough for most people in enough places that only hardcore purists want to work close to the underlying cloud infrastructure that it runs on.

Key Points

• VMware’s main audience is enterprise IT infrastructure groups, who are particularly concerned with operating infrastructure, not just building infrastructure.
• Developers, meanwhile, want to care very little about infrastructure and simply consume it as they do public cloud: as a dynamic, abstract, software-defined resource.
• Infrastructure is a cost centre to enterprise businesses, while developers are closer to the value-generating applications the business relies on, so developers influence a great deal of IT infrastructure spending.
• VMware needs to keep both groups happy at the same time, which means presenting different interfaces to the same infrastructure to different groups with different needs.
• Project Cascade is the key to VMware’s success in achieving this goal, allowing developers to speak Kubernetes to vSphere while IT groups continue to use their existing tools.

VMware is trying to chart a path to continued relevance in a world where public cloud is mainstream and the mindset it requires takes over from more traditional approaches to on-site infrastructure.

We see all the major public clouds making inroads back into the traditional datacentre; AWS Outposts, Azure Stack, and Google Anthos are all examples of public cloud providers trying to give customers the same cloud experience they’ve decided they like, but in places that aren’t the vendor-run public cloud regions.

For all the enthusiasm for public cloud, the majority of IT infrastructure spend is still on servers, storage, and networks that live in a datacentre somewhere. The rise of so-called edge computing simply increases the amount of infrastructure that isn’t inside a public cloud’s proprietary datacentres.

Cloud State of Mind

We’ve long argued that cloud is a state of mind, not a physical location. Cloud is about an operating model, a set of processes and techniques, which values flexible, highly elastic infrastructure that is controlled with software. The hard engineering work of making it happen is hidden behind software abstractions that developers interact with, blissfully unaware of Spanning Tree Protocol or RAID configurations.

This is something that infrastructure has always tried to do. We don’t write software that needs to deal with block placement on disk platters, we have filesystems and storage controllers that deal with it for us. We use things like write() or S3 GET instead, and stand on the shoulders of giants that came before us. Most organisations buy these abstractions from vendors, and then operate them using staff or contractors with widely available skills.

Kubernetes is just another layer of abstraction over the top of datacentres, and it provides a useful way to not care very much about how exactly the cloud underneath actually works, provided the cloud infrastructure has been well designed. The people who operate this infrastructure are broadly available, and the skills acquired at one organisation are readily portable to another.

Kubernetes Is Too Hard For Enterprise

Yet Kubernetes remains too hard for most enterprises to use in practice. Instead of employing dozens—or hundreds—of staff who are world-class experts in designing and running Kubernetes environments, most enterprises would prefer to buy a product that works from a vendor whose business is to be experts in such things. Few enterprises build their own servers or storage arrays, for example, while the public clouds definitely do.

Right now, enterprises who want to use Kubernetes have to commit to acquiring Kubernetes expertise, in a constrained market where the skills are relatively rare. The public cloud offerings are very different to their traditional IT systems, so it’s a substantial commitment no matter how Kubernetes gets used. And it requires running your IT in two isolated silos at once: as traditional infrastructure, or as new cloud-like infrastructure.

VMware can provide a path here to adopting the way of doing software that the developers prefer, but without throwing away existing investments in IT operations, and without forcing developers to become operations people. It’s a useful middle-ground that helps people move from one way of doing things to the other over time.

VMware as Cloud Abstraction Layer

Kubernetes provides the foundation for a cross-system compatibility layer that looks essentially the same no matter where it runs, be it on bare metal servers in a private datacentre, as a public cloud -as-a-Service offering, or in IoT devices at the edge. The dream is to be able to bundle up software as a container that can be shipped to any, or every, deployment location and run there as if it was running on a developer’s laptop.

It’s clear that developers are enjoying the API-driven nature of cloud infrastructure, but the actual job of building and running that infrastructure still needs to be done by someone. In public cloud, it’s handled by the vendor. AWS originally, and now Azure, Google, IBM, Alibaba and a host of others. Yet each of these platforms has its own, often unique and therefore incompatible, approach.

With Project Cascade, VMware has a path to move from being a virtual machine orchestrator to being a container orchestrator as well. VMware has been attempting to appeal to developers for some time, but with limited success. We feel this limitation has come from its attempts to make VMware appealing to developers, rather than changing VMware to be what developers already like, which is public cloud, and now Kubernetes.

With Project Cascade, it looks like VMware has decided to try this second approach, but without abandoning its existing customers who know and like VMware as it is. To developers vSphere will look like Kubernetes, while to operators vSphere will look like traditional VMware and Kubernetes, depending on how far through the transition to cloud-native operations they are. Operators can add new cloud-native operations techniques on top of older approaches, and gradually replace them over time as they acquire skills and expertise.

By providing a common way to run containers no matter where the infrastructure lives, VMware could become the de facto standard for infrastructure in the enterprise. It might not be used for everything but if you know you can readily hire admins who know how to operate it, and developers who can write code that runs on it, there’s a lot of network effects that will encourage you to stick with this approach.

A lot will depend on how well the Cascade interface into VMware aligns with developer expectations, and how much change it forces on existing VMware admins. Developers expect something that works the way Kubernetes works in general, so proprietary weirdness will need to provide outsize benefits compared to the environments they already know and like.

IT admins, ironically, may be the ones to benefit the most from the success of Cascade. IT operators are already starting to adopt more software techniques such as infrastructure-as-code, and the greater levels of automation that these techniques allow. Helping the infrastructure operators to become more like developers, rather than expecting developers to learn to operate infrastructure, is probably the key to success here.

We advise keeping a close watch on the processes that Cascade enables and how much of a bridge it provides between the traditional IT infrastructure world and that of the developer in cloud-native Kubernetes land. If developers respond positively, and operators aren’t forced to change too quickly, VMware may be on to a winner here.