When Project Pacific was first announced back in 2019, most of the focus was on Kubernetes and how it would be re-architected into vSphere, basically the "how" or the implementation details. As much as I enjoy diving into the tech, what really stood out to me about Project Pacific was the implication it would have on workload evolution for vSphere.
In fact, I wrote about this very topic in this blog post: Project Pacific - Workload Evolution in vSphere because I felt that most of the focus was only on the "how" but not the "why". Here is a quote from the blog that summarizes why I was excited for Project Pacific:
However, Project Pacific is actually more than just Kubernetes but with all the new lingo like Supervisor and Guest Clusters, one can easily get lost in the implementation or what I would refer to as the "how" part of Project Pacific. If you ask me, the "why" part is much more significant and Project Pacific is fundamentally re-defining what and how to deploy a workload in vSphere.
Fast forward to today, vSphere with Tanzu has been delivering on the vision of Project Pacific since its introduction with vSphere 7 back in 2020. Developers, DevOps and Platform Engineering teams can easily deploy workloads like Tanzu Kubernetes Grid Clusters (TKC) or Virtual Machines into a vSphere Cluster that has been enabled with vSphere with Tanzu, also known as a Supervisor Cluster.
While the current vSphere with Tanzu experience works well for most environments with a handful of Supervisor Clusters, but what happens when you need to support more users, teams and an increased number of Supervisor Clusters across different locations? How do you manage access control for these users and the compute resources that they can consume while providing a simple and intuitive developer ready interface? This is where VMware Cloud Consumption Interface (CCI), formally known as Project Cascade comes in!
