Cloud

Introducing VMware Cloud Automation Services (CAS)

@mpoore

• 5 min read

My focus on a day-to-day basis for most of the last five years has been on cloud automation and orchestration, more specifically with VMware vRealize Automation (vRA) and VMware vRealize Orchestrator (vRO). I've worked with a variety of customers in different verticals (government, finance, service provider) to help them design and deploy an automation platform and create services to automate many use-cases, both common and unique.

So naturally, my interest in a software-as-a-service (SaaS) platform that does the job too was always going to manifest itself. The day has arrived though that VMware are officially launching that service. Yesterday, January 15th 2019, VMware Cloud Automation Services became generally available.

(GA is perhaps a little misleading in this case though. As a SaaS offering, it was there already – there's no new version to download. What has changed though is that a number of features that were initially not present, but planned, are now there and ready for use.)

I'm not going to go too deep at the moment as I have a whole journey planned out that I want to share. For now I'm just going to provide a brief overview of the three complementary services that form the CAS offering:

  • VMware Cloud Assembly
  • VMware Service Broker
  • VMware Code Stream

Before I get in to it though, a few general words on CAS and some on vRA too.

Being SaaS services, VMware CAS takes away some of the operational overhead of maintaining a cloud management function as the deployment, scaling, upgrades and availability tasks are managed by VMware. That leaves more time to focus on delivering value to the businesses consuming these services. It's also important to note that CAS has been developed as an API first solution.

A SaaS solution may not be an option for everyone. In those instances vRA is still going to be an option – it's not being deprecated in favour of CAS. If you're already familiar with vRA, you'll probably notice some familiar concepts in CAS but there are also differences. The key one is, of course, the deployment model for vRA.

Time now though to touch lightly on the three services that make up CAS.

VMware Cloud Assembly

Cloud Assembly is the service that enables cloud administrators to configure and manage resources and map functions to users. It's also where blueprints for machines, applications and services are defined by blueprint developers.

The functions offered to cloud administrators are:

  • Configuration of the cloud infrastructure to which users deploy their blueprints. This can be Azure, AWS, vSphere (via an appliance called a Cloud Proxy) or even VMC on AWS (again using a Cloud Proxy).
  • Set up projects to link the service users with the infrastructure resources. The closest match to projects in vRA are business groups. Projects are a way of mapping cloud consumers / users to business functions.
  • Import blueprints and OVA files to support blueprint developers using the marketplace. This enables blueprint developers to consume OVA files, templates etc for constructing blueprints. Mappings between templates and machine sizes can be created for each cloud to abstract some of the detail away from the users. For example, mappings could define what “Small Ubuntu VM” means in AWS, Azure and vSphere. There's a growing library of sample blueprints building up on the marketplace that can easily be imported to jumpstart your own CAS journey.
  • Delegate the user management and blueprint infrastructure to project managers or other staff. Depending on the size of the business you're supporting and what use-cases you're trying to cover, you may choose to delegate the creation of blueprints, or not.

Blueprint developers do exactly that – create blueprints. On the face of it, the blueprint designer looks a bit like the one in vRA (7.5).

Cloud Assembly blueprint designer

There's the menu of components on the left, the canvas in the middle and a YAML representation of the blueprint on the right. The example above is a simple linux VM, but with the numerous components on the left almost any combination is going to be possible.

VMware Service Broker

VMware Service Broker is the shop window for CAS. It's where catalog items are listed and consumed and where provisioned or deployed items are managed. Whilst it may sound simple, there's still a lot to it when you start to dig around.

Service Broker catalog

Again, the look may seem familiar to those with recent (7.5) vRA exposure. The experience is broadly similar, but also slicker. More on that in a future post.

VMware Code Stream

The third service in the triumvirate of VMware CAS, is VMware Code Stream. (The name may sound familiar – remember vRealize Code Stream?)

As with its on-premise progenitor, Code Stream enables you to create pipelines that model a software release cycle and continuously integrate and deploy software applications. Code Stream can connect to cloud-based and on-premises endpoints to deploy software by leveraging blueprints and catalog items created in the other services. It's possible to then trigger pipelines when developers update their code, and use a project to group pipelines and related components.

Code Stream is the most developer-centric of the three services and will perhaps be the one most alien to people from an infrastructure / operations background. I'll try and go easy on this one, especially as I'll be learning as I go!

Next Steps

For me, and the journey I'm going to be documenting here, my next steps are stepping through the configuration of the individual services in the context of a fictional organisation (my own lab – o11n.lab) as I have already got access to CAS. I deliberately kept this post brief and high-level.

If you're curious about the VMware CAS services, your recommended next steps are set out below.