Hello my name is VMware Cloud Assembly!

The first new VMware Cloud Service is Cloud Assembly. Cloud Assembly is a multi-cloud provisioning service. You could compare this with the policy based automation and graphic blueprint designer we know from vRealize Automation.

Multi-cloud environments are not new, Almost every customer I go to uses some form of cloud besides their on premises infrastructure. But running a cloud environment is not easy, let alone run multiple clouds and try to run and control it in an easy and efficient way. VMware Cloud Assembly will help cloud users to create and deploy applications but it also can enable cloud flexibility and choice, and control risks.

How? Developers want the same experience of automating deployment and consumption of infrastructure and applications in private and hybrid clouds as they get with public clouds. Cloud Assembly delivers unified provisioning across all clouds through declarative Infrastructure as Code. Cloud Assembly provides an abstraction layer across multiple clouds. This abstraction normalizes infrastructure constructs without sacrificing the richness from each of the clouds! In essence, with this abstraction layer VMware abstracts underlying cloud infrastructures as they abstracted hardware by using a hypervisor. 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. Cloud Assembly uses priorities and tags to guide the deployment to the desired location(s).

A cloud administrator determines the appropriate clouds, necessary tiering, network requirements, etc. He defines them in the underlying clouds and assigns priorities and tags to comply to the company requirements. For example: For development, a company wants to use AWS with fast and encrypted storage and a public and a private network. For production this company uses vSphere with Gold/Silver/Bronze datastores and a public and private network. He than assigns a #dev tag to AWS and a #prod tag to vSphere. He assigns a #public tag to both AWS and vSphere public networks and a #private tag to the private networks. Last action is to assign #gold/silver or bronze tags to the storage and he’s good to go.
A developer can now create and deploy his content and use these tags to determine placement when coding or at deployment time.

Access Cloud Assembly using GUI

User can use the GUI to create their blueprints but, as you can see in the screenshot above, the infrastructure-as-code is created on the fly. You can drag and drop items on the design canvas or you can edit the code. Here you can design your desired IT service in a declarative way and publish it to the Service Catalog. Versioning is included in the product so you can easily see the differences between your current and earlier blueprints, you can restore previous version, unrelease versions and even publish multiple versions of the same blueprint to the Service Catalog.

Access Cloud Assembly using API

Cloud Assembly provides a Cloud API layer that is utilized by its 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 (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.

In the introduction we discussed seven questions people always ask when discussing a cloud automation platform. Let’s see how Cloud Assemble tackles those.

Which public clouds can I connect to?

Cloud Assembly now supports vSphere including NSX, AWS, Azure, VMware Cloud on AWS and VMware VMC Partners.

Can I deploy one service to multiple clouds?

Yes, Cloud Assembly enables you to design services which are trully cloud agnostic. Cloud Assembly uses image and flavour mappings to ‘translate’ which image or template to use when deploying for instance a small Ubuntu virtual machine on AWS, Azure or vSphere.

When you require specific functionality that’s only delivered by a specific cloud provider you can still define cloud specific services.

Can I use the native cloud services?

This is probably one of the most asked questions and probably the coolest new feature in Cloud Automation Services. Cloud Assembly is able to use the native services delivered by cloud providers like AWS and Azure.

Why this is cool? You can now design a new application stack which uses a virtual machine running your proprietary code and using an AWS RDS instance as a database backend. This unleashes all the power and development offered by the public cloud providers.

How long does it take to install and configure?

Although VMware delivered vRealize Lifecycle Manager which dramatically reduces the time it takes to deploy a vRealize environment, setting up a vRealize cloud management environment can take up a lot of time. Cloud Assembly is Software-as-a-Service, so the only thing you need is a VMware Cloud Services account and a credit card.

Very important to mention is that Cloud Automation Services is not here to replace vRealize on-premises products. It is merely here to offer VMware customers a choice. Do I want to install a cloud management solution on-premises or do I want to use it in a SaaS form-factor.

Is this offered as Software-as-a-Service?

With vRealize Automation the answer was ‘No’. now that VMware has Cloud Automation Services, this answer is a definite ‘Yes‘. But the choice for Cloud Assembly or vRealize Automation all depends on the use case you are addressing. Cloud Assembly and vRealize Automation differ in functionality, so it will depend on the use cases.

Again! Very important to mention is that Cloud Automation Services is not here to replace vRealize on-premises products. It is merely here to offer VMware customers a choice.

Are changes in a blueprint propagated to the deployed instances?

With Cloud Assembly you can change your blueprint and commit these changes to already existing deployments.

Do you support Infrastructure-as-Code?

Yes! User can use the GUI to create their blueprints and the infrastructure-as-code is created on the fly. Users can drag and drop items on the design canvas or you can edit the code, use the method that you prefer. Or you could even create these blueprints through the API. All the goodness in Cloud Assembly is configurable and consumable using the method that you prefer. Are you an infrastructure admin who like the GUI? Fine. Are you a developer and want to use the API and deploy infrastructure-as-code. Even better!

What I really like is the possibility to see what I change in the blueprint. Don’t you hate it when you have a working situation, you change some items or settings and it suddenly fails. I hate it even more that I have to remember what I changed and roll back these changes and hope I get a working situation again. Now with Cloud Assembly, I can easily see the changes I made, as seen in the screenshot below, and revert to a previous version.

More information can be found here.