VMworld 2018: A first look at VMware Cloud Assembly – Cloud Management-as-a-Service

About a year ago I published an article on the “VM automation cloud service”: VMworld 2017: VM Automation cloud service (tech preview).
A technical preview of a brand new SaaS service focussed on automation & orchestration, building blueprints and infrastructure as code. Now a year later, there is a big announcement: VMware Cloud Assembly is available!

The VM Automation service of last year has grown to a production ready SaaS offering. This new offering actually consists of three different, tightly integrated, services:

  1. VMware Cloud Assembly – focussed on cloud management, projects and creating & deploying blueprints;
  2. VMware Code Stream – a service that can automate a development pipeline;
  3. VMware Service Broker – a self-service portal offering capable of providing access to IT services/project that are developed in Cloud Assembly.

You might think here, ey…that sounds like “vRealize Automation as a service”? Well, from a functional perspective I might agree to a certain level, but from a technical perspective this is a complete new offering. It’s a SaaS platform, running in the cloud and leveraging cloud native principles. But from the other hand, if you look at the new vRealize Automation 7.5 interface, you will see a lot of similarities.

In this article we will have a look at Cloud Assembly, the solution that is used to define your endpoint (called Cloud Accounts), resources, projects, placing policies, blueprints, deployments and marketplace. Let’s dive a little deeper into this solution.

Cloud Assembly is a cloud management tool that fully supports different cloud platforms, with a true focus on all these different platforms. There’s support for:

All these platforms are added as Cloud Accounts in Cloud Assembly. NSX-T and NSX-V are used in conjunction with a vSphere/vCenter Cloud Account. For the public cloud accounts you can define which regions are allowed for provisioning.

For on-premises accounts (like vCenter) you have to deploy a “Data collector”, this is lightweight virtual appliance that is deployed in your vSphere environment. This virtual appliance will connect to the on-premises vSphere environment using a pre-configured service account, but also connect to the Cloud Assembly SaaS service. No special firewall requirements are applicable here, the only thing is that the Data collector should be able to connect to the on-line service.

You can also configure so called integrations. Currently both Puppet and vRealize Orchestrator are available as an integration. The vRealize Orchestrator (running on-premises) also leverages the data collector (same counts for the NSX type cloud account), and allows you to run vRO workflows from the SaaS service.

After you’ve successfully created a Cloud Account, it’s time to setup a Cloud Zone.

Cloud zones enable you to group a set of compute resources and assign capability tags to the zone.

They are based on accounts/regions, so you must have at least one cloud account configured before you can create a cloud zone. Cloud zones define where and how blueprints configure deployments.

You can have one or many cloud zones assigned to each project based on priority and limits.

So a Cloud Zone is the link between a group of resources linked to one or more projects. You can assign capability tags to the zone, that can be used in a blueprint to decide on which Cloud Zone is the best candidate for a deployment. These capability tags are extremely powerful and help you to make a distinction between cloud versus on-premises, or test/dev versus production deployment.

Another important construct in Cloud Assembly is a project. A project allows user/groups to deploy their blueprint to linked Cloud Zones. Currently there are two roles in a project: a project member and project administrator.

We’re almost up at creating our first blueprint, but before we can do that it’s beneficial to define Flavor and Image mappings. This is really a very powerful feature of Cloud Assembly. Flavor and Image mappings allow you to use the same blueprint for different types of clouds. If you leverage the “cloud agnostic” constructs in a blueprint (more on that later), you can use exactly the same blueprint for Azure, AWS and vSphere! This is really a very powerful feature: design once, use it on different clouds.

Before you use this option, you have to define Flavor and Image mappings. A Flavor is the link between a pre-defined VM “t-shirt size” (nano, small, medium or large) and the actual size in Azure, AWS and vSphere. An Image mapping is the link between a Guest OS that is used in the VM, and the template that should be used in the connected clouds. For example: which image should exactly be used in AWS, Azure or vSphere if Ubuntu 16.04 LTS is defined in a blueprint.

Now we’ve setup a Cloud Account, a Project, Flavor and Image mapping, it’s time to build a first blueprint:

The blueprint design screen is divided in three columns: a list of available components, the actual design canvas and the infrastructure as code pane:

In this example a Cloud Agnostic machine is used; this type of machine can be deployed to AWS, Azure and vSphere. On the right side you the code for this virtual machine:

inputs: {}
resources:
  Cloud_Machine_1:
    type: Cloud.Machine
    properties:
      image: Ubuntu-16.04-LTS
      flavor: nano
      networks: []

In this example a flavor called nano and image called Ubuntu-16.04.LTS is selected, which are linked to a specific size and AMI (Amazon Machine Image) in AWS. You can add a network to the blueprint, and make a selection using constraints and capability tags:


The IAC for this blueprint is:

inputs: {}
resources:
  Ubuntu01:
    type: Cloud.Machine
    properties:
      image: Ubuntu-16.04-LTS
      flavor: nano
      networks:
        - name: '${MyNetwork01.name}'
          assignPublicIpAddress: true
  MyNetwork01:
    type: Cloud.Network
    properties:
      name: MyNetwork01
      networkType: existing
      constraints:
        - tag: 'AZ:eu-central-1c'

In this example a network is connected, and the capability tag “AZ:eu-central-1c” is used. The deployed VM will be connected to the default network in AWS AZ eu-central-1c.

After you’re satisfied with your blueprint, you can create a version (yes! versioning is included in Cloud Assembly) and/or create a deployment.

A deployment is an actual instance or item that is created based on the blueprint.

The supercool thing is that you can create a new deployment, or update an existing deployment. In the case of an update, Cloud Assembly will update your existing deployment so it is compliant with the selected blueprint version. Cool things are happening here!

A simple “deploy” will start the deployment, and after a couple of minutes your deployment will be available:

And of course in AWS:

I hope this will give you a first impression of the capabilities of Cloud Assembly. More articles on this new service will follow soon, so stay tuned!

Browse

Article by channel:

Read more articles tagged: Cloud