What is Cloud Assembly?

At VMworld 2018, VMware announced their new Automation service, aptly named Cloud Automation Services (CAS) and earlier this year in January, it was announced as General Availability.

So what is CAS? Well it’s a multi cloud solution driven by the infrastructure as code methodology and delivered by VMware as a SaaS model. CAS is made up of 3 components, Cloud Assembly which allows for infrastructure and application delivery in line with devops principles, Service broker which provides a service catalog and finally code stream which focuses on the pipeline and continuously delivery. Some of these names will be familiar, e.g code stream but you should note that these are not just upgrades of previous products and they have been written from scratch for a brand-new experience.

In this post, I wanted to focus on Cloud Assembly and give a brief introduction to the service. I have been using vRA for a number of years and one main problem was the pain of installation. In short, different products stitched together (think of the SQL and postgres DB fight) meant it was a real pain to deploy consistently as part of an overall private cloud product.

Cloud Assembly

The key aspects for me in Cloud assembly are the cloud agnostic blueprints and the fact that it is really tag driven which allows us to deploy infra as code delivered via YAML files. We can version our blueprints and also we can automate Multi Cloud service delivery. CAS has an API first approach which means that many items are not available on the GUI. When we compare to vRA which was very GUI centric. For me this is a huge step in the right direction from VMware and as someone who had to install, configure and maintain vRA a lot this comes with real added value to the business

Cloud Assembly Infrastructure

Access to CAS is controlled by projects. These can be used to organize where users can deploy blueprints in your environments. Once we have a project we can start to look at CAS and understand the concept in more detail and then deploy our blueprints.

So, it’s clear one main feature is the ability consume resource from public or private clouds. To do this we must first create cloud accounts. A cloud account is a pointer to an endpoint, whether it be vCenter, or regions in AWS, Azure or GCP. Cloud Zones are a grouping of regions that you set in your cloud account. Zones allow us to apply tags to, for example, a specific datastore which enables us to distribute our machines as we wish. As an example, let’s say I have a datacentre with 4 clusters and I want to deploy test VMs only to the development cluster. We can create a tag named “dev” and apply this to the specific cluster. Likewise, in AWS if I have an associated region which is made up of multiple zones, then I can apply the tag to specific zones in this region where i want my test VMs to reside.

Flavor mappings are a representation of a VM size, so for example if we create a “Small” flavour size then we can subscribe our blueprint to this and depending on the endpoint this could be a 1cpu/1RAM VM in vCenter or a t2.Micro instance in AWS. Likewise image mappings allow us to create a generic name for an OS, eg ubuntu and then associate this with a template on vCenter or a image in AWS.

We can also create profiles for our storage and networks which will allow us to select the LUNs/Port groups we want to attach respectively. Once again, we can provide tags to these and use as part of blueprint.

Blueprints

There are two types of Blueprints. Traditional endpoint blueprints or what is more existing, a cloud agnostic blueprint – how cool! This means we can define virtual machine settings in a single blueprint and deploy to several endpoints regardless of it being in the public cloud or on premises.

If you look inside the blueprinting tab, it might look familiar to later versions of vRA you have used, where you can drag and drop components into your blueprint, however an addition is the ability add code inside it by updating the YAML file dynamically. The other impressive feature  is that YAML file lets you define your inputs, so for example we can utilize tags as input to relate to VM size, network profile or storage policy. Tags are really at the core of CAS.

You can also version your blueprints which means you can go back to previous versions or call a specific version from the API request. Additionally you can use the CAS marketplace which allows you to consume preconfigured blueprints

Tags

As i have touched on, Tags are fundamental to CAS. To better understand, let me use the below image to try and explain clearer. During deployment, a consumer will enter input details regarding endpoint, type of OS and size of the VM instance. These inputs would all be based on tags which are defined in the cloud agnostic blueprint. As such there could be multiple endpoints which subscribe to this tag. In the example below, we can see we have 4 endpoints, 2 in Dev and 2 in Prod. Because the consumer is selecting to deploy on Dev then CAS will rule out both production environments. It will now see that there are still 2 valid choices for deployment – AWS and vCenter. It will move onto the images available and see that both endpoints subscribe to the Windows 2012 R2 tag. However it will finally see that only vCenter fulfills the full request to deploy a Small VM and therefore deployment will begin on this environment.

Summary

There you have it, i hope this gives you a quick overview of Cloud Assembly and some if its capabilities. This is by no mean an full overview of the product but i hope to give a bit more information in the upcoming Q1 VMUG in Glasgow. Thanks!