Introducing VMware Cloud Assembly, VMware Code Stream and VMware Service Broker

Many of our customers have a multi-cloud strategy and expect seamless experience across hybrid and native public clouds. They are interested in using all the richness that each cloud has to offer but at the same time they want policies to govern placement and utilization of their workloads across clouds.

We have kept these needs in mind and embarked on the next step in our journey to provide our customers with seamless, multi-cloud experience. Today, I am excited to announce three new automation-focused VMware Cloud Services. These SaaS offerings provide programmable provisioning across multiple clouds.

Let me introduce each of these services:

VMware Cloud Assembly

Let’s start with Cloud Assembly, which is our multi-cloud provisioning service. For VMware SDDC-based virtual infrastructure, it offers the ability to create a private cloud. The user can create provider constructs such as cloud zones that provide compute, storage, network, load balancing and security services for a specific set of purposes. These zones can cover different compliance and security needs, provide location or workload segregation and be used for multi-tenancy. These constructs also map to equivalent constructs on public clouds.

Cloud Assembly also provides an abstraction layer across multiple clouds. This abstraction normalizes infrastructure constructs without sacrificing the richness from each of the clouds! Policies use this abstraction layer to broker workload deployments between various clouds. For example, if the policies dictate different locations for dev and test workloads, then Cloud Assembly will deploy them to the right locations. If the policies dictate gold tier for data intensive workloads, then Cloud Assembly will use the gold tier for those workloads. To aid troubleshooting, Cloud Assembly maps and shows how it evaluated the policies and arrived at its decisions.

Cloud Assembly provides a Cloud API layer that is utilized by its templating engine (we call them Blueprints). The Cloud API can also be used by 3rd party tools or by products such as Pivotal Cloud Foundry, Pivotal Kubernetes Service, etc.

While the Cloud API is there, many customers would prefer to use declarative templating constructs, which we call ”Blueprints”. Our blueprints can deploy cloud agnostic resources (compute, storage, network etc.) across clouds. They also support native services provided by public clouds, such as AWS RDS or AWS Lambda. You can create a hybrid cloud blueprint that deploys a VMware-based workload and also utilizes a native cloud service. For example, in VMware Cloud on AWS, you can deploy a VMware-based application that also uses an AWS S3 service! And finally, the blueprints will also address deployment of Kubernetes applications. Creation of these blueprints can be done through Graphical UI, as YAML in the CLI panel or through the API.

Finally, Cloud Assembly will also support the extensibility mechanisms for private cloud through vRealize Orchestrator workflows and event-broker subscriptions.

VMware Service Broker

Service Broker has three main roles:

It is a catalog (or storefront) for curated templates from multiple clouds
It governs usage of templates and services through policy definition and configuration
It is a broker between Cloud Assembly-managed services and 3rd party managed services (hence the name)

The basic use case is creating a storefront where one can publish curated templates, such as, Cloud Assembly Blueprints, AWS Cloud Formation Templates (CFT), Azure Resource Manager (ARM) templates, VMware vRealize Orchestrator-based XaaS templates, Kubernetes Helm Charts, etc. One can assign access policies on these templates to other project members within an organization. One can also simplify the consumption of these templates using custom forms. These forms can simplify retrieval and specification of input variables from external sources.

In a multi-cloud environment, it is very important to be able to manage templates, services and resource usage through policies, such as, access policies, lease policies, resource usage policies, quota or capacity policies, approval policies etc. Service Broker enables these policies.

And finally, Service Broker will support brokerage of services across clouds and orchestration systems. This will help central engineering or IT teams to play the role of the broker of services enabling developers to consume these curated services. Consumption becomes intuitive through the graphical UI or API.

value

VMware Code Stream

We want to bring the productivity gains from DevOps to developers and administrators of both infrastructure as well as applications. Code Stream is primarily a continuous delivery service. It includes many pre-built continuous integration plug-ins for development tools (e.g. Git, Jenkins) and orchestration systems (e.g. Kubernetes). Whereas Cloud Assembly automates infrastructure or application deployments, Code Stream improves productivity by automating the deployments though various stages leading unto production.

Many of the innovations in Code Stream come from our own use of Code Stream to develop our products! As a result, we have pre-built templates for container deployment strategies for Kubernetes, such as, canary deployments or blue-green deployments or rolling upgrades. The continuous delivery pipeline also has enterprise-class capabilities such as nested pipelines. And we also have out of box dashboards to help spot issues and improve release efficiency.