This series of posts is focused on the VMware Cloud Automation Services (CAS), which contains three separate but related services. These services represent VMware’s intent towards the multi-cloud market, focused on ease of consumption, and delivering a choice of consumption methods.
Cloud Assembly
The first service is Cloud Assembly, which allows you to describe application infrastructure as code, and then use it to provision either native cloud objects, or more portable cloud agnostic IaaS constructs using intent based placement.
The image above shows how quickly you can get started generating IaC using the design canvas. You may be thinking to yourself “this looks more like Infrastructure as UI than Infrastructure as Code”, and in some ways you would be right. You can certainly work natively in an IDE to describe your infrastructure, but from experience kickstarting your code with the design canvas is a huge productivity improvement. Once it is generated you can either save it in Cloud Assembly for others to use, or keep it yourself and interact with it via a local CLI.
How can you control placement with agnostic components? You’ll have to follow this series to find out.
Service Broker
The second service is Service Broker, which provides the capability to aggregate both Cloud Assembly blueprints and alternative native infrastructure as code (IaC) definitions. These can then have policies associated with them, and be presented into a catalog with which end users can interact via UI or API. The image belows shows how simple it is to pull through Cloud Formation Templates into Service Broker.
Codestream
The final service is Codestream - a product that shares a name but not much else with the existing vRealize Codestream product. It is a powerful continuous delivery pipeline with some nascent continuous integration capabilities.
Code Stream allows you to pull together the various automated steps in your release process and knit them together in a single pipeline - from Jenkins builds, to Kubernetes deployments and many things in between - even smart templates to handle canary and blue/green upgrade scenarios.
In the next post, we will start getting a bit deeper on Cloud Assembly.
| This post is part of a series. |
|---|
| Part 1 - This Article |
| Part 2 - Basic Blueprinting in Cloud Assembly |
| Part 3 - Blueprint Versioning in Cloud Assembly |
| Part 4 - Getting Started with the Cloud Automation Services API |
| Part 5 - Working with Blueprint Inputs |