Extensibility has a long history within VMware’s Automation and Operations suites. Extensibiltiy has traditionally been defined as how we create interactions with platforms outside of our management platform. Some of the most common examples of this are…
- Interacting with IPAM Systems (Infoblox, BlueCat, etc)
- Pushing records into Configuration Management Databases (CMDB’s)
- Creating Records in DNS
- Interactions with various REST platforms
In Cloud Automation Services, we have refined existing, and introduced new extensibility capabilities in the platform. The goal of this post is to give you an overview of the extensibility options that exist in the platform today, and how you can use them to extend Cloud Automation Services beyond its native capabilities.
Extensibility in a Multi-Cloud World
In Cloud Automation Services, we offer the following Options for native extensibility in the platform
- vRealize Orchestrator (vRO)
- Action Based Extensibility (ABX)
vRealize Orchestrator (vRO)
vRealize Orchestrator has had a long history within the Cloud Management Business Unit at VMware. vRO is a workflow engine at its core – but one of its biggest values is the plugin community it has fostered. A large number of vendors and partners have created plugins that simplify execution of advanced workflows from within the platform. A vast portion of these plugins were designed with extensibility in mind and extending vRealize Automation native capabilities. Many of these workflows can be redesigned with Cloud Automation Services in mind to accept that property bundle instead.
Beyond the native workflows that exist in the platform, vRealize Orchestrator offers the power of the “Scriptable Task”. This object in vRO allows you to free form code actions directly in JavaScript.
Workflows are constructed with a number of Input and Output variables, attributes, and parameters. Running a workflow natively outside of extensibility would yield a form that expects inputs, and when these inputs are provided – the execution would progress. When building vRO workflows for Cloud Assembly extensibility, we leverage a “properties” object that takes the Cloud Assembly property bundle inbound. These properties are then parsed and interacted with against several other objects within the workflow (or across other workflows).
How do I obtain it? Where does it run?
vRealize Orchestrator is included in Cloud Automation Services and is downloadable via the Integrations > vRealize Orchestrator menu. This downloads an OVA appliance that can be installed in a vCenter environment.
Combined with the Cloud Automation Services “Cloud Proxy”, vRealize Orchestrator can execute workflows during the various lifecycle stages of a machine deployment. More on that later!
Action Based Extensibility (ABX)
Action Based Extensibility is a new entry in Extensibility for VMware. ABX runs as Function as a Service, currently hosted in AWS running as Lambda, and in Azure running as Azure Functions. This capability was previous highlighted by Kaloyan Kolev in this blog post. You can see a sample action below!
These lightweight Actions allow users to construct their cloud native extensibility in either Python 3 or NodeJS – languages that the modern developer is intimately familiar with. Today, ABX is heavily tuned for extending functionality against public cloud workloads; being that it natively runs in those cloud environments (Azure/AWS).
These actions expect a property bundle to be delivered from Cloud Assembly that we can then parse via code to take actions against. This property bundle is largely the stock and any additionally added properties via the blueprint YAML.
Actions can be chained together leveraging Action Flows. These Action Flows function very similar to traditional vRO workflows in the sense that they are able to be sequentially executed; but have the added benefit of quick execution time and being extremely lightweight.
Native Versioning and Git Synchronization
Another key tenant of ABX is that Actions can be synchronized with source control. This capability is going to be detailed in a blog post very soon, but the short of it is that these actions can easily be committed into a GitLab or GitHub repository – creating a truly “Infrastructure as Code” approach to extensibility!
In addition to the standard capabilities of Actions, they also have a native versioning capability. We can track changes against previous versions and release these versions for publishing in Service Broker.
Actions can also be exported and stored locally if you wish. These exports contain the data about the actual “Action” itself, as well as the configuration parameters for the Action.
API Driven Automation Against Itself
A topic which will be highlighted in an upcoming post is the unique ability that ABX has to call the Cloud Automation Services API’s directly, leveraging the configured user’s authentication scope, This allows ABX to automate CAS directly over the vast REST API. Only specific endpoints are exposed for this capability – but keep an eye on this space as it will continue to grow!
Controlling Execution Through Lifecycle
In vRealize Automation 7.x we introduced the concept of the Event Broker. The Event Broker was an engine that allows us to create Subscriptions against various events within the platform. These events were most typically lifecycle states. Examples of these lifecycle states can be seen below.
We take vRealize Orchestrator and ABX Actions and bind them to Event Broker states through Subscriptions. These Subscriptions also indicate which properties would be passed into the extensibility action. There are a number of configurable items when constructing these subscriptions.
Some key callouts during configuration of a subscription
- Filter events allow us to limit execution based on specific properties or characteristics
- When we select our runnable item (vRO workflow or ABX Action) we are provided with some context specific configuration items
- When we enable blocking workflows, we can prevent further flows or actions from running until the execution completes
- Enabling blocking also exposes the “Recovery Item” as a potential run that can be used to run extensibility items that would back out a failed run
Wrapping Up
Cloud Automation Services, specifically Cloud Assembly, provides a number of ways to interact across external platforms across multiple clouds. For users who are heavily invested in the vRealize Orchestrator platform; we provide the capability to consume vRO workflows. For something more “Cloud Native”; we offer Function as a Service via ABX. There’s a ton of great capabilities coming to extensibility within the Cloud Automation Services platform, and we’re barely scratching the surface!
Visit https://cloud.vmware.com to sign up for a 30 day trial of Cloud Automation Services today, and see how you can extend your Clouds!
