Choosing the Right vRealize Automation Extensibility Module

Data center extensibility

When designing or implementing a VMware vRealize Automation (vRA) environment, choosing the right type of plug-in to support data center extensibility will quickly define metrics for time-to-value in the solution. Let's take a look at the options.

VMware marketplace

VMware's solution exchange marketplace is the first place to look when trying to find a workflow package or VMware vRA blueprint to complete a specific automation task. OEMs and partners will post their extensibility modules for vRA and vRealize Orchestrator (vRO) here, as well as content packs for vRealize Log Insight and management packs for vRealize Operations. For example, you can integrate ITSM with ServiceNow and vRA using VMware's plug-in. Or you can further automate an Ansible Playbook with vRA by adding governance, approval policies, event subscriptions, ITSM, IPAM and a service catalog with a plug-in from SovLabs.

VMware's marketplace this isn't the only place to find workflows or blueprints. I've seen cases where newer plug-ins are exclusively available on OEM websites. I've also found what I'm looking for on VMware's code site, and of course on IT community blogs. This includes sample blueprints for installing applications like Harbor, Git, Kubernetes and more.

When you've exhausted all these options, you can turn to the developers on WWT's Application Services team to build a solution from scratch. That could even mean building the API first! Or it could mean creating Ansible or Puppet content and then calling it from vRA.

Extensibility packaging

VMware vRA supports several different methods to automate data center tasks:

vRO Plug-In: A packaged solution created with the VMware software development toolkit. It contains all the workflows, actions and scripts necessary to automate the cloud. It can leverage custom dynamic types for management of components through the vRO inventory tab.
vRO Package: A vRO package is a collection of workflows, actions, config elements and resource elements exported from one vRO system that can be imported into another. Typically something that uses the resources and configurations tab for managing components for the package as opposed to dynamic type.
vRA Blueprint: vRA supports many types of blueprints including cloud, machine, multi-machine, container and XaaS (Anything as a Service). These blueprints define the service being offered by vRA. For example, a multi-machine blueprint that maps NSX switching, clones VM templates of apps and installs software components while calling vRO workflows to setup additional tasks and services.
Software Component: A software component is Infrastructure as Code (IaC) in the sense that we can build the components directly in vRA using scripting languages like Bash, Windows CMD or PowerShell. Components provide applications and middleware to provisioned machines as they are being built, managed and retired.

Benefits and drawbacks

The following are pros and cons to the extensibility packaging being provided through various forms:

Community
- Freely available
- Minimal support (forums and blog comments)
- Often requires manipulation to work for your custom environment
- Not always up-to-date with newer versions (becomes an issue when API changes in vRA occur)
OEM (Free)
- Freely available
- Best Effort Support
- Code is easily modifiable
- Not always up-to-date with newer versions of the OEM's product or vRA
OEM (Licensed)
- Requires purchase of license and support (one year, three years, etc.)
- Supported by the vendor
- Very stable with minimal manipulation
- Usually workflows are read-only, so requires duplicating if customization required
- Typically up-to-date, but I've seen up to six months behind vRA and OEM product releases
Third Party (Licensed)
- Examples include SovLabs and Tech Data
- Requires purchase of license and support (one year, three years, etc.)
- One partner supporting integration points for multiple vendors, simplifying deployment, support and ongoing integration
- Often backed by the OEMs they integrate with, like Veeam working with SovLabs
- Typical quarterly updates and aligned with the latest vRA versions
- Usually workflows are read-only, so it requires duplicating if customization required
- Very stable with little-to-no manipulation
WWT Professional Services
- Requires purchase of services for custom integration work through as statement of work (SOW)
- Typically a one-off designed to solve a particular use case
- Could be manipulation of a package from OEM, community or third party
- Can also be created from scratch
- No ongoing support without another SOW
- The code is yours, allowing you to modify as needed
- Up-to-date at the time the code is written (additional services needed to update later)