Authored by Mark Johnson, Chief Architect, Cloud Consumption Interface
Last week we announced the Initial Availability of Cloud Consumption Interface as part of VMware vSphere+. We think this new technology is going to dramatically expand the ways vSphere is used.
Cloud Consumption Interface is a cloud experience for Supervisor IaaS services. To the consumer of virtual machines, disks, Kubernetes clusters, etc. it is a graphical web console, common IaaS API endpoint, and CLI for self-service access to a vSphere-based cloud. To the provider of infrastructure services, Cloud Consumption Interface allows providers to define the Regions, application resource envelopes, and resources that consumers can self-service access.
Cloud Consumption Interface enables enterprises to develop applications with increased agility and modern techniques on vSphere while still maintaining control of their infrastructure. Because Cloud Consumption Interface leverages Supervisor IaaS services, it offers a cloud endpoint for all the Kubernetes-based, desired state IaaS APIs available in the vSphere platform. Users can continue utilizing the kubectl CLI commands and IaaS object YAML definitions that exist today with vSphere Supervisor, and these now accessible with Single Sign-On from a cloud endpoint. Users can now manipulate applications in many Regions with many Supervisors as easily as a single Supervisor today.
Cloud Consumption Interface, powered by Aria Automation, is included with a vSphere+ subscription. With vSphere+, it’s just a few clicks to enable Cloud Consumption Interface and begin offering a self-service IaaS cloud layer within an enterprise.
A Modern Cloud Layer for Modern Applications
VMware’s approach to modern applications on vSphere is unique in that it offers compute, storage, networking, and other IaaS objects and services all via a Kubernetes-based API in the Supervisor introduced in vSphere 7 (originally introduced as Project Pacific).
Cloud Consumption Interface extends the functionality of these APIs for creating modern applications by adding its own Kubernetes-based APIs for describing and manipulating cloud-level constructs, and it also adds Single Sign-On capabilities for easily proxying the Supervisor Kubernetes-based IaaS APIs from a cloud endpoint to wherever the infrastructure is running. In addition, Cloud Consumption Interface offers a browser-based GUI for viewing and manipulating IaaS service objects’ Kubernetes-based desired state resources.
Consumption Starts with a Namespace
To use vSphere Supervisor IaaS services, a user must have access to a Supervisor Namespace. All user-managed vSphere Supervisor IaaS resources are created within the scope of a Supervisor Namespace.
Cloud Consumption Interface makes it easy for users to request a new Supervisor Namespace. After a user is assigned privileges within a Project, that user can go to the Cloud Consumption Interface and click “+ New Supervisor Namespace”. The user doesn’t need any more detailed knowledge of the infrastructure behind this – instead, the user just chooses a NamespaceClass and then decides on a name and Region for their Namespace.
NamespaceClasses
In Kubernetes APIs, it is typical to choose the type of object that is desired from a set of “Class” objects. For example, in typical Kubernetes applications, users create a PersistentVolumeClaim to get a block volume by specifying a particular StorageClass backing that volume.
A NamespaceClass in Cloud Consumption Interface represents the type of Supervisor Namespace that users can request. Administrators can decide what resource envelopes and resource types they want to expose to their enterprise users for self-service and encode those in a NamespaceClass.
NamespaceClasses are assigned to particular Projects. As an example, a Project may be assigned a NamespaceClass for test/dev purposes that is more limited in resource footprint but has access to a wide variety of VM images. Another Project may be assigned multiple NamespaceClasses for production application purposes with larger resource footprints, but those NamespaceClasses may make only particular production secured, vetted VM images available to the user.
Choosing the NamespaceClasses available to particular Projects provides a level of governance to the cloud administrator. NamespaceClasses are also valuable when placing a Namespace within a Region — knowing the anticipated resource footprint upfront helps the scheduler place the Namespace on an appropriate Supervisor.
Think of Supervisor Namespaces as an IaaS application organization construct with its own privileges for controlling user access and with resource limits that can be applied. Think of NamespaceClasses as templates of different Namespaces that can be selected for the appropriate application usage and help provide placement guidance for the anticipated application.
Regions
In Cloud Consumption Interface, a Region is a list of Supervisors. Each enterprise determines what Regions make sense for their environment. VMware’s recommended best practice is to have similarly configured Supervisors within a Region so that Namespaces can be placed anywhere within the Region and have similar capabilities.
In Cloud Consumption Interface, creating and using a Namespace works similarly whether an enterprise has small or large Supervisors, one or many. To the consuming user, they can choose a NamespaceClass and a Region that’s available to them without worrying about the infrastructure configuration behind the scenes.
Users can utilize Regions to co-locate different applications within the same Region in different Namespaces or to be able to run their application in a particular Region that’s local to particular users or other service dependencies.
Everything is a Kubernetes API
For the consuming user, Cloud Consumption Interface gives them a consistent API and CLI to interact with for all their cloud and IaaS operations.
Listing projects, viewing regions, viewing NamespaceClasses, creating Namespaces, creating VMs or TKG clusters or disks or load balancers – all of this can be done with a Kubernetes-style API and the kubectl CLI.
When using the CLI, the Cloud Consumption Interface cloud layer Kubernetes API Server is listed as a kubectl context after logging in. This is the kubectl context used to list Projects, list accessible Regions, and list the Supervisor Namespaces in each Project. This is also the kubectl context used to self-service create new Supervisor Namespaces via the CLI.
The magic behind the scenes is a cloud layer proxy for communicating with the vSphere Supervisors. Logging in to Cloud Consumption Interface via the CLI populates each Supervisor Namespace as a kubectl context that gives the user CLI access to that Supervisor Namespace, with communication proxied appropriately to the underlying Supervisor, without the user needing to log in more than once or worry about their own network connectivity to the underlying vSphere Supervisor.
A Cloud Endpoint for Supervisor Access
Via Cloud Consumption Interface, users can access any Supervisor Namespace within any Supervisor in any Region they have permission to use. A new Kubernetes API Cloud Proxy that runs within Cloud Consumption Interface, hosted by VMware, can proxy communication to agents automatically deployed as part of the vSphere+ Developer Experience enablement, which is the workflow that turns on Cloud Consumption Interface.
Users can manipulate any of their applications via APIs or via kubectl without requiring direct network connectivity from the user’s computer to the underlying infrastructure of the application. This proxy communication is one element that helps achieve a Single Sign On experience for users – users just log in once and can access all of their applications on all of the connected underlying infrastructure.
Identity
Cloud Consumption Interface leverages the VMware Cloud Services Platform (CSP) integration into vCenter which gets automatically configured with vSphere+ to trust CSP-issued tokens. Cloud Consumption Interface proxy communication flows can transparently exchange the user’s CSP token for the appropriate token to allow communication to the particular Supervisor that is powering a particular application.
Users can log in once to the cloud layer and access any Supervisor Namespace, even in different datacenters or regions.
Because the access to the Supervisor Namespace is controlled through Kubernetes RoleBindings in the Supervisor, the access to Supervisor IaaS services can be granted in the Supervisor layer without needing to give the consuming user any additional access to vCenter.
IaaS Service Graphical User Interface (GUI)
In addition to a GUI for self-service Namespace creation, Cloud Consumption Interface provides a GUI for Supervisor IaaS Services and objects supplied via those services.
Users can use these browser-based UIs to quickly see what VMs or TKG Clusters are running within a Namespace. There are guided creation workflows that allow users to choose options for creating a new VM, new TKG Cluster, or independent disk.
As users step through the selection items for a new object, the Kubernetes YAML for those objects also appears within the UI. This is a great way to learn about what options exist for writing Kubernetes object YAML directly in the future.
To use a GitOps workflow, it’s easy to use the object creation GUI to select desired options, download the object YAML, and then save that to a git repository for execution via a pipeline.
Application Availability
All cloud connectivity and ease of use of Cloud Consumption Interface is achieved while still maintaining application availability within the vSphere infrastructure.
The source of truth for the desired state of the VM, TKG, and other IaaS objects is still maintained within each Supervisor in the infrastructure. Object states can be modified within that Supervisor via API access within that Supervisor or directly to the Supervisor, even if connectivity to the Cloud Consumption Interface is disrupted.
Due to the proxy communication described above, all IaaS objects are always directly manipulated on the Supervisor running on the vSphere infrastructure. This design was chosen to avoid any issues with multiple sources of truth and to avoid any object state collisions or object synchronization concerns between the cloud layer and the infrastructure layer. This design also means that applications can continue to run and be modified and maintained without worrying about constant cloud connectivity.
Because the fundamental control plane for the IaaS is running within the vSphere clusters as part of the Supervisor, TKG and VM, applications running on those Supervisors remain just as available as they are today.
Summary
We’re excited to offer Cloud Consumption Interface as part of vSphere+. This is a cloud experience built with modern application development, self-service access for users, administrative governance, and vSphere application availability all designed in from the start.
