vRealize Automation 8.0 - Let's Talk About XaaS


vRealize Automation 8 vRealize Automation Cloud

Published on 12 December 2019 by Christopher Lewis. Words: 1769. Reading Time: 9 mins.

Purpose

One of the recurring themes I hear when talking to people in the community but also when talking to customers there is a perception that vRealize Automation 8.0 does not have an Anything as a Service (XaaS) capability. This is not true and hopefully the following article will paint a clearer picture of what vRealize Automation 8.0 can actually do in this space.

Background

What is vRealize Automation 8.0?

VMware released its new Multi-Cloud Automation platform, vRealize Automation (vRA) 8.0, just before VMworld 2019 Europe in November 2019.

VMware vRA 8.0 is essentially an update to the current on-premises product (vRA 7.6), but in my view it is more than just a version increment, it provides a modernisation of the underlying architecture to support VMware’s modern multi-cloud vision. You no longer need to deploy Windows or Microsoft SQL Server to use vRA!

Technically, vRA 8.0 is the on-premises version of the vRA Cloud Software-As-a-Service (SaaS) offering (which used to be called Cloud Automation Services). With pretty much full code parity between the two products, people now have a choice of how they would like to consume vRA.

There are two key difference between the On-Premises and SaaS based offerings:

  1. Features/Functions Release Cadence - new features will be delivered first in vRA Cloud on a regular cadence and, eventually, those features will find their way into a future release vRA 8.x.
  2. vRealize Orchestrator - vRA 8.0 includes vRealize Orchestrator 8.0 as a micro-service within the Appliance, whereas vRA - Cloud uses a SaaS enabled vRealize Orchestrator deployed within the on-premises datacenter.

What is XaaS?

I personally think that the term Anything as a Service (XaaS) is pretty self-explanatory but, just so we’re all on the same page, my definition of XaaS for this article is:

Anything as a Service (XaaS) provides the capability to automate ANY business or IT process that can be accomplished via API, Script or CLI.

As with any sort of process automation, the expectation is that automation with XaaS will reduce the likelihood of human error, increase standardisation, increase overall efficiency, increase productivity and allow IT to concentrate on innovation.

Common examples of XaaS (with suitable plug-ins) may include:

  • Active Directory User Account/Group/OU Management.
  • Physical Firewall Changes.
  • Configure Backup Software / Policies.
  • Standardise the Snapshot of a Virtual Machine.
  • Run Configuration Management Jobs (such as Puppet Enterprise).
  • Running software installations post deployment.
  • Convert a Virtual Machine to a Template.

The Anything As a Service (XaaS) Conundruum

vRealize Automation XaaS Comparison

So now we have an understanding of what XaaS is, let us take a look at the high level differences between its implementation in vRA 7.6 and vRealize Automation 8.0.

XaaS Capability vRealize Automation 7.6 vRealize Automation 8.0
Publish Business Process (vRO) Yes Yes
Publish Business Process (ABX) - Yes
Custom Request Form Yes Yes
Create Custom Resources Yes No
Create Resource Mapping Yes No
Publish Custom Resource Actions Yes No
Consume XaaS in a Blueprint Yes No

XaaS in vRealize Automation 7.6

If we look in a little more detail at what is available in vRA 7.6 for XaaS, the following capabilities exist:

  1. Create XaaS Blueprints to publish vRealize Orchestrator (vRO) workflows as Catalog Items in the Service Catalog and allow Entitled Users (within a Business Group) to consume them.
  2. Create Custom Resources to enable vRO objects to be mapped as a manageable object in vRA.
  3. Create Resource Mappings to create a mapping between a vRA Catalog Resource Type and a vRealize Orchestrator Inventory Object (for managing objects outside of XaaS).
  4. Create Custom Resource Actions and publish them to Entitled Users on both Native Resources (such as vRA VMs) and Custom Resources.
  5. Consume XaaS Blueprints on the blueprint canvas to run them as part of a larger deployment.

Note: A built-in example of Resource Mapping would be the mapping of a vRA Virtual Machine type to a vCenter Virtual Machine (VC:VirtualMachine) object in vRO).

XaaS in vRealize Automation 8.0

If we look in a little more detail at what is currently available in vRA 8.0 for XaaS, the following capabilities exist today:

  1. Publish a vRO Workflow as a Catalog Item to Entitled Users so they can be requested.
  2. Publish an ABX Action as a Catalog Item to Entitled Users so they can be requested.

Don’t worry, I know what you are thinking…

Are you REALLY sure vRealize Automation 8.0 can do XaaS?

Yes - The reason I still say that vRA 8.0 can deliver an XaaS Capability is because when people say they ‘do XaaS’ in vRA 7.6 they generally do not use ALL of the advanced XaaS capabilities. What they actually mean is that they want to automate an IT or Business Process and allow it to be consumable through a Service Catalog by anyone who is entitled to use it.

And that is something we CAN do in vRA 8.0 and with the new #awesome Custom Forms feature we can even do it with #panache!

Note: The Custom Forms feature is available in vRA 8.0 for both XaaS and IaaS Blueprints. In vRA 7.6, this feature was for IaaS Blueprints only.

But, what about Custom Resource Actions in vRealize Automation 8.0?

Yes - You can achieve the same functionality of Custom Resource Actions in vRA 8.0, just in a slightly different way.

If we consider that, in vRA 7.6, a Custom Resource Action is essentially a vRO workflow that has been published as a Resource Action that is linked to the context of the vRA object (such as a Virtual Machine) using Entitlements.

Now whilst Custom Resource Actions are not currently available in vRA 8.0. This functionality can still be achieved with a little effort. Essentially a Resource Action normally has a mandatory input (which is the object you’re trying to perform the Action on) and we need to simulate this with a ‘wrapper’ that enables the selection of the object. This is actually common practice today when trying to do the same thing using vRA 7.6. This wrapper workflow can be published into the Service Broker like any other workflow.

Using this approach to developing Custom Resource Actions has a number of benefits:

  1. You can publish ABX based Resource Actions in the Service Catalog.
  2. You can publish ABX or vRO based Resource Actions for objects that are not natively supported (or managed) by vRA.

Do I need to refactor my workflows to work in vRealize Automation 8.0?

The simple answer would be; it depends. It will depend on what the workflow does, what it interacts with, how complex it is and what the result is..

I personally would expect a significant number (if not all) of vRO 7.x workflows to work in vRA/vRO 8.0, with the following caveats:

  1. If you have a workflow that calls the vRA7.x CAFE or vRA7.x IAAS (.NET) API then these will not work as those APIs will not be available in vRA 8.x. The reason this is even an issue is twofold:
  • One of these common practices in vRA 7.x was to front IaaS Requests with an XaaS form (vRO Workflow) to enable intelligent selection of blueprints, workload placement or network selection in an effort to reduce the number of Catalog Items within the Service Catalog. I personally always advised against this, opting instead for the simplicity of multiple IaaS Blueprints over the technical debt of XaaS.
  • Some people created XaaS Workflows to create vRA constructs and objects such as Business Groups, Reservations etc so they could be published and consumed as Catalog Items.
  1. If you have a workflow that uses a vRO plugin that isn’t supported (or more importantly doesn’t work) in vRealize Orchetsrator 8.x, then that workflow may also need to be reviewed.

I would strongly recommend running the vRealize Automation 8.0 Migration Assessment Wizard that will help you highlight potential issues with automated Workflow migration in the future. However, remember you do not have to wait for automated migration, you could manually move your workflows now!

Do I need to wait to vRealize Automation 8.x to migrate my vRO workflows?

No - You can manually migrate content from vRO 7.x to vRO 8.x and, assuming no refactoring is required, consume those in the Service Catalog.

Do I need to migrate all my workflows into Action Based Extensibility (ABX)?

There is absolutely no hard requirement to migrate vRO workflows into ABX. Should you do it? The answer to that is enough for a dedicated blog post!

Key Takeaways

Based on my time in the field doing VMware PSO consultancy, the two typical use cases for Anything as a Service (XaaS) were:

  1. Publish business processes to a Service Catalog for consumption by Entitled Users.
  2. Allow Entitled Users to perform Day 2 Custom Resource Actions on objects within vRA.

Both of these Use Cases can be completed using vRA 8.0. I would actually say that vRA 8.0 is better than vRA 7.6 at publishing vRO workflows to a Catalog especially with the new style custom forms integration. In terms of Day 2 Resource Actions, as I highlighted above, this is something that can be worked around with relative simplicity.

So for the Use Cases outlined above, vRA 8.0 does XaaS!.

Final Comments

Firstly, Thank you for staying with me on this post. It was a long one (some 1700+ words with no pictures!) but hopefully this has provided a little more clarity on the XaaS capabilities in vRA 8.0. I truly think vRA 8.0 (and vRA Cloud) is definitely going in the right direction to solve the problems we have gained with multi-cloud automation. I do acknowledge that, in some respects, vRA 8.0 (and vRA Cloud) still has some feature parity gaps when comparing with vRA 7.6, but rest assured those gaps are the key focus for the developers. But I also feel it is important to acknowledge that there are key features in vRA 8.0 that users have been asking for (including native support for public cloud services and git integration) that make vRA 8.0 a perfect choice for multi-cloud automation. Luckily in my current role, I get to engage with the Product Management team every chance I get and this enables me to feedback what people want to see!

From a personal point of view, I think it is really important not to be tied to the fact that some functionality existed previously but doesn’t currently exist, especially if you are not actually using it! I have lost count of the conversations I have had which start “we can’t adopt vRA8 because of XYZ” and when I actually delve into the details, they can actually achieve what is required just in a different way.

Published on 12 December 2019 by Christopher Lewis. Words: 1769. Reading Time: 9 mins.