Limited XaaS Functionality in vRA 8
I want to start off by mentioning that VMware is listing Anything as a Service (XaaS) as being “built in” to vRA 8.0. The current implementation of XaaS in vRA8 is only a subset of the functionality that is available in vRA7. In the second part of this series, I am going to point out why the current implementation of XaaS in vRA8 falls short of where it should be before any customer requiring XaaS considers using it in a production environment.
I will also note that we see a lot of customers using XaaS in vRA7 to customize the platform so that it meets their organization’s specific requirements. To level-set for this discussion, here are the major features/capabilities available in vRA7:
- XaaS Blueprints that do not create a catalog item
- XaaS Blueprints that do create manageable Catalog Items
- XaaS Day 2 Actions (Resource Actions)
- Custom Resources – ability to create anything as a provisioned manageable object in vRA
- Resource Mappings – ability to correlate between vRA Catalog Resource type and a vRO type for custom resource actions
- Component Lifecycle – ability to define lifecycle (Provisioning, Update, Destroy) actions for an XaaS Blueprint with a Custom Resource output type.
- Ability to call XaaS blueprints inside of other blueprints (Nested XaaS Blueprints)
Today, the only feature of XaaS that is available in vRA 8.0 is item #1 above. The bulk of what XaaS does in vRA7 is not currently available in vRA 8.0. Also note that, as I speak about XaaS, I am referring to the product specifically as it pertains to vRO, not the ABX component. From what I have been able to uncover with ABX, it certainly doesn’t appear ready to support any of the advanced XaaS capabilities above, although it does appear that you can address item 1 in the list above using ABX today.
What is available in vRA 8 XaaS?
Before we talk about what is missing, I want to highlight what you get with XaaS in vRA 8.0 by way of a simple workflow example. The way that XaaS is implemented in vRA 8.0 today, it is configured from Service Broker (not from Cloud Assembly; more discussion on that later). If you navigate to Content & Policies > Content Sources, you can add a New Content Source that matches one of the following:
Since we are working with XaaS (specifically with vRO) we select the vRealize Orchestrator Workflow option. I can then select the workflows I want to expose with this content source (Note that only one workflow can be exposed via a single content source). I select a workflow called New Datacenter, and then “Create & Import” my content source.
The New Datacenter workflow is a very simple workflow, in which the user submits the name of a new datacenter they would like to create in vRO. The outputs of the workflow include the actual VC:Datacenter object that was created in my vCenter.
To share the content with your project, you go to Content Sharing, and then Add Items.
From here, I then select the My XaaS Workflows Content Source I created earlier.
At this point I can access the New Datacenter Request from my catalog, I can submit a request, and I can see that the request completes successfully.
I can also log in to vCenter and view the Datacenter that I requested.
That is what I have been able to identify as the extent of what XaaS in vRA 8.0 is capable of today. You can import a vRO workflow in to Service Broker, expose that workflow in the catalog, and allow the user to submit the workflow from vRA. That workflow can even be used to create things (a datacenter in vCenter in this example), but XaaS is currently incapable of returning that object back to vRA to become a managed object in vRA itself. You’ll note below that the resource that shows on the canvas for this deployment is a “workflow”, rather than the actual datacenter object that we created. You can see the inputs and outputs for the workflow, but there is nothing of value added to our catalog. That datacenter is not added in to the vRA lifecycle, nor can it have actions executed against it.
What is not available in vRA 8 XaaS?
I’m going to tackle this subject first, because the lack of availability of this feature very likely plays into why the the other features are also missing. Without the capability to allow vRA to recognize vRO types, there is no way that vRA can understand what the items are that are being provisioned. Also, vRA would not be able to create a manageable catalog item, allow you to call a day 2 action on that item, or define a lifecycle around that item. In vRA 8.0, Custom Resources are not currently available.
As an example, if your organization has a requirement to automate the creation of a new user account, you could use the vRO Active Directory plugin to create a new user account. The workflow may have an output type of AD:User, in which the newly created user account can be passed out of the workflow. Where custom resources come into play here is that the output type of AD:User is not something that the vRA catalog understands right out of the box. A custom resource allows you to make vRA aware of the vRO “type” so that an AD:User can be created as a manageable vRA catalog resource. You can place leases around that object, you can govern any second day actions presented to that object, you can create and present actions on that object to allow the AD:User to be deleted directly from the vRA portal. You are able to treat that AD:User just like any other catalog resource by automating the entire lifecycle of that AD:User object.
Where Custom Resources become even more powerful is when you take into consideration the dynamic types plugin available in vRO. The dynamic types plugin allows you to create new types that are defined by the user without having to understand the vRO SDK; they are defined through a series of vRO workflows and actions written in vRO itself. Side note: see earlier article covering dynamic types here. With the dynamic types plugin, you could define a type for anything you can dream up, and then wrap that object in the lifecycle control processes available in vRA. If your endpoint vendor does not have a vRO plugin available for the management of their resources, but they do have a REST API available, you could create a Dynamic Type for the resource created by a REST call to that endpoint so that the resource is now visible in, managed by, and included in the vRA lifecycle.
Third-Party Vendor Custom Types
In addition, without the availability of Custom Resources, third-party vendors are restricted in their ability to present their content directly in the vRealize Automation Catalog. Also, a third-party vRO plugin that has a Custom Type defined in vRO cannot be pulled in to the vRA catalog by a user.
Day 2 XaaS Actions
The capability to create custom vRO workflows and then call those workflows directly from a resource in the catalog as a second day action does not exist in vRA 8.0. We have seen quite a few customers that identify this specific functionality as a crucial requirement in their decision making process on when to migrate to vRA8. The out of the box vRA actions do not meet the requirements for their organization (or they have custom actions to perform for their deployments), whereas the XaaS Second Day Actions in vRA7 met this requirement.
The ability to correlate between a vRA Catalog Resource type and a vRO type for custom resource actions does not exist in the present state of the product.
In addition to XaaS Blueprints being inaccessible in Cloud Assembly, even if a developer were to create an XaaS blueprint in Service Broker, they cannot consume that XaaS blueprint as an additional canvas item because nested blueprints are not currently available in the product.
XaaS is Only Available from Service Broker
As I understand it, one of the largest drivers behind the development of vRA8 using industry accepted standards for YAML blueprint development was to enhance the vRA experience as it pertains to organizations with a DevOps-heavy focus. vRA 8 has made massive strides in making the Cloud Assembly portion of vRA8 very accessible for the DevOps-minded organization. Your developers now have the access and capabilities to do some really cutting edge blueprint development and to be able to test and deploy resources directly from Cloud Assembly without ever having to work with a service catalog (Service Broker). Having seen these forward-focused improvements, I was somewhat surprised to learn that the ability to utilize XaaS blueprints is only available in Service Broker, and not from Cloud Assembly itself.
If your organization’s requirements for XaaS falls into one of the buckets listed above, I would certainly proceed with caution when considering vRA 8.0 for production deployments. Instead, I recommend keeping an eye out for improvements in the XaaS functionality in vRA 8.1 and 8.2.