Cloud Wars: VMware Cloud Assembly and the Wild World of Extensibility & Orchestration

May 19, 2020

Tweet This:
Share on LinkedIn:

By Steve Kaplan, Kovarus, SDDC & Cloud Management

For the final section I’d like to cover VMware Cloud Assembly. I turn to the area in Cloud Assembly that I think is the most essential to deliver on complex use cases and has undergone the most evolution: Extensibility & Orchestration.

I tend to break these up into two different categories:

  1. things we do can control within a blueprint
  2. things that are extended capabilities outside of the blueprint using event-triggered subscriptions

Blueprint Extensibility

Cloud Assembly blueprints offer up very powerful orchestration capabilities, particularly in the arena of defining dependency ordering for provisioning operations. In the extensibility arena, cloud-init scripts or a configuration management tool such as Puppet Enterprise or Red Hat Ansible Tower can be leveraged to provide customization inside the provisioned operating system. Let’s take a simple example of how this can work in practice with a blueprint I mocked up:

In this example, we have a very simple two-tier application architecture. Both web and database are on the same logical network segment, and multiple web servers will be deployed as part of this request. A role for each type has been defined inside our Puppet Enterprise instance (could also be done just as easily via Ansible Tower), which we will apply to the systems, so they are essentially ready to use with all required apps/packages. To support the multiple web servers, a load balancer will also be provisioned. The key things I want to highlight here:

  1. The purple box shows the relationship between the load balancer and the web servers. These servers are added to the load balancing pool as part of the deployment
  2. The green box shows a dependency placed between the web and database resources. What this means is that web machines won’t be provisioned until the database server has completed its provisioning operation and has moved onto deploying the Puppet agent and applying the role. Alternatively, depending on goals and how this application works, you could just as easily put the dependency on the web role not even starting the act of provisioning VMs until Puppet finishes for the database as well.
  3. The red box shows the dependency of Puppet roles and may be the most essential piece here. Depending on what is going on, the web/app piece may need to be able to talk to a database, so making sure that the Puppet run for the database has completed successfully is critical to ensuring the web can as well.

While much of these capabilities were possible under older versions of VMware vRealize Automation (vRA), combining this simple dependency model in conjunction with all of the services/capabilities that can be consumed out of the box provides a very robust orchestrated deployment without ever having to write a single line of code in a language such as Python — all you’re doing here is connecting boxes and filling in some required fields in the YAML blueprint.

Event-triggered Subscriptions

For anybody familiar with past versions of vRA, Event-based Subscriptions (EBS) is likely not a new topic, and is likely to be something that has been used in conjunction with the capabilities inside of a blueprint. To summarize how this capability fits into the grand scheme, think of it this way: VMware has defined events in the lifecycle of manageable resources that can be used as trigger points for extensibility actions utilizing either action-based scripts / functions that are lightweight and generally thought of as “Function as a Service” (FaaS), or utilizing VMware vRealize Orchestrator (vRO) workflows when more complex requirements present themselves. We will cite some examples of where each of these capabilities may be used to achieve the intended result.

As in previous versions, the concept of blocking for relevant event subscriptions applies in Cloud Assembly Extensibility in the same way as it did previously. If the selected event topic supports it, the option to set the subscription to block other subscriptions from executing until the currently running one completes will operate as it did previously.

Action-based Extensibility

We start with the Action-based Extensibility (ABX). ABX actions are categorized into one of four types:

  • REST Request: This is the most basic of option and is essentially just a template for executing a REST request against an API. At this time, using this particular type is very limited, mainly for very simple integrations activities with an API.
  • REST Poll: This is largely the same as the previous, but with some smarts built in. If executing a long-running API operation, you may want to periodically check on status and determine status. This type of action allows for defining the number of intervals to poll, as well as timeout and how many retries should be taken.
  • Script: This option provides the most flexibility, as it’s a free-form scripting option where you can develop your own scripts/functionality in the language of your choosing, as long as you’re choosing Python, PowerShell, or Node.js! At this time, this seems to be the most popular option available as, unlike the previous two, you can pass parameters into the scripts from the deployment, as well as pass out results to be used later in the deployment cycle.
  • Flow: This option allows you to chain multiple actions together to deliver a theoretically simplistic workflow, albeit these are going to be fairly simplistic workflows.

Places we’ve seen the use of ABX as a replacement for traditional workflows is for implementing of relatively simple API integration. Whether that comes in the form of a REST request/poll or using a script that would have largely been cumbersome to develop and execute in vRO, it is much more straightforward when you’re developing in a language you may be more comfortable with. Some examples of this could be:

  • Creating or updating a configuration item in an ITSM tool such as ServiceNow
  • Creating, updating, or closing a service ticket when provisioning operations execute
  • Executing a CI/CD pipeline in a tool such as Jenkins
  • Developing an IPAM plugin if one is not available for your organization’s platform

All of these can be executed within AWS, Azure, or on premises. For on-premises execution, vRA Cloud requires the use of an extensibility appliance deployed within the on-premises environment, or these capabilities are built into an on-premises vRA deployment.

VMware vRealize Orchestrator (vRO)

vRO has been around as a product for a long time, but really rose to prominence with VMware’s acquisition of DynamicOps, and the evolution of vRA as a whole. While ABX can provide simple workflow capability via the Flow type, there are a few important differences that should be noted where vRO may be preferable:

  1. Credentials: ABX does not currently support secure strings or credential management for REST targets with one notable exception: custom IPAM integrations that use the IPAM framework and the credential store used by cloud accounts and integrations. vRO will have a wider range of support options for authenticating to RESTful APIs.
  2. XaaS: If you want to be able to develop self-service use cases for APIs that need to be standalone capabilities and/or custom day-2 operations, the ability to create custom resources is going to depend on vRO.
  3. More Complex Use Cases: While ABX is great for simple, quick API interactions, if you’re looking to create workflows based on more complex logic like a decision that could have more than two branches, or utilize plugins like the one for vSphere to perform customization of VMs or other resources, vRO will provide a better platform to meet those needs.


That’s the lesson for the day! As you can see, there is no “right” answer in a vacuum — aligning the requirements around the best available method, combined with trying to minimize the amount of custom code that needs to be sustained, should be the driving principle in approaching extensibility and orchestration for a given use case.

Looking to learn more about modernizing and automating IT? We created the Kovarus Proven Solutions Center (KPSC) to let you see what’s possible and learn how we can help you succeed. To learn more about the KPSC go to the KPSC page.

Also, follow Kovarus on LinkedIn for technology updates from our experts along with updates on Kovarus news and events.