A VMware Admin’s First Impressions of vRealize Automation 8 (vRA8) — Part 2 of 2

Welcome to Part 2 of 2 of our “First Impressions” of vRA8 article. In Part 1, we discussed what’s new, good, not so good, and really good about Documentation and Tagging in vRA8. Below, we discuss ABX and policies, which are both very new and very different in vRA8.

{{cta(’58c71586-bbe1-4867-bf96-b66ee58b4caf’,’justifycenter’)}}

Action Based Extensibility (ABX), vRealize Orchestrator and Extensibility

ABX is the new extensibility offering packaged with vRA8 (in addition to vRealize Orchestrator) that uses a FaaS provider (AWS, Azure and On Prem offered today) to provide extensibility for the new platform. As someone who has spent countless hours working with vRO, ABX is probably one of the more intriguing announcements surrounding vRA8. 

One of the things that I am impressed with right out of the gate is that the ABX action runs show you the code that was used as well as the payload that was passed for use in the action. In fact, both Orchestrator and ABX runs can be monitored directly from the Cloud Assembly UI. No more having to log in to a separate interface to see what is happening with your extensibility. This methodology makes troubleshooting much more accessible.

I come from a background heavy in vRealize Orchestrator and am not a true developer. From that point of view, ABX actions and action flows (a way of chaining actions together like a workflow) are certainly learnable; however, without a library of code samples available to start with, it may take a while to learn. In ABX you don’t have the standard vCenter or vRA plug-ins that came bundled in recent versions of vRO; in fact, even in vRO8 the vRA plug-in is gone. 

The implications that this change could have on your migrations as a customer could be quite staggering. If you have written a ton of complex extensibility code that centered upon using the vRA plug-in for vRO, you’re going to have to re-write all of it using REST. That’s not necessarily bad news. Even in vRA7, I personally prefer working with REST over the plug-in, but it will be necessary to re-tool all custom code prior to migrating to the new platform in addition to the potential learning curve for REST if your staff is not already familiar with REST. 

vRealize Orchestrator 8 has removed the Java client entirely, and has migrated entirely to a web interface similar to what was available in vRA7.6. While I wasn’t a fan of the vRO Java client, I think that the way the workflows were organized in a hierarchical folder structure was very intuitive. In the limited amount of time that I have had to work with the new vRO web client, I have found that trying to find a workflow by search does not always return the results I was expecting. For example, when attempting to “Add a vCenter Server Instance”, I couldn’t quite recall exactly what the workflow was called. In the old version I could have navigated to Library > vCenter > Configuration to find the exact workflow needed. In the new UI, I ended up opening the old vRO client in 7.6 to find the name of the workflow I needed after 3 failed attempts at searching for the workflow. This scenario very well may be user error, or just old habits that are deeply ingrained from working with vRO since 5.x, but I miss the folders.

Entitlements and Policy Definitions

The entitlement constructs of past versions of vRA are now gone, and they have been replaced by policies in Service Broker in vRA8. These policies are in many ways more flexible, but also remove some of the granular permissioning that was present in vRA7 entitlements.

Organization-Level Policies: In vRA 6.x/7.x, I had spent a considerable amount of time writing custom workflows to copy entitlements from a “template” business group out to all of the other business groups (150+). The template business group had three separate entitlements, each one pertaining to a different function (administrative, service account oriented, or end-user). All in all, we had in excess of 450 entitlements and we needed all of them to match the corresponding entitlement tied to the template business group. If we needed to add a single action that we wanted entitled to all 150 of our business groups, we would have to first entitle that action in the template business group, and then run the workflow that copied the entitlements out to the other 150 business groups. In vRA8, it appears that this process has been addressed with the ability to add a policy at the organization (rather than project) level. With the policy in the following screenshot I am able to specify that all project administrators have access to all 2nd day actions in the system within their respective projects. You probably wouldn’t want to do this in a production environment, but it showcases some of the added flexibility inherent in vRA8 policies. 

Wildcard Policy Selection: In past versions of vRA7, you didn’t have the option to specify, for example, that your administrative group be entitled to all machine level actions. Instead, you had to individually select each of the 20+ actions you wanted to entitle to administrative users of the business group. In vRA8, policies have a feature that allows you to specify a wildcard at any level of permissioning so that you can easily grant all permissions at the level required. 

For example, to entitle every single action for every single type, you would simply select the ‘*’ wildcard:

If you wanted to grant access to every vSphere level action, you would select Cloud.vSphere.Machine.*

Or if you had a user that only needed access to actions for vSphere Disk and Network related actions, you could do the following: 

Individual Group or User Policy Assignment: In the previous example with the template business group we had those base level actions, but we also had requirements where we would create specialty entitlements within a business group to entitle specific actions above and beyond the base entitlements that all users would see. These specialty entitlements would then be assigned to individual users or a Security Group in the Business Group that held a subset of the users in the business group that were often not administrative level members. In vRA8 policies, there is currently no mechanism for assigning granular permissions to a subset of the members or administrators in a project. Policies are applied to either Administrators or Members of the project. 

Catalog Item Policies: When you go to create a new policy, you may notice that the capability to restrict access to Catalog Items in vRA8 is no longer available. The only options that you are presented with are Lease Policy or a Day 2 Actions Policy. 

It seems that Catalog Items are entitled to the project as a whole and there is no way to filter the available Catalog Items on an individual user basis. Quite a few of the customers we work with require the ability to restrict access to not only 2nd Day Actions, but to Catalog Items as well within a project. 

Summary

vRealize Automation 8 is here. VMware has made massive strides in many areas to improve upon user feedback from past versions. Cross-Cloud capabilities are markedly enhanced in the new version, and Infrastructure as Code is now a reality for vRA blueprints. Whether your first foray in the vRealize Automation world is on version 8, or you’ve worked with vRA/vCAC since the DynamicOps days, there is a learning curve ahead. Start to work with vRA8 now in development and stay aware of updated releases as you methodically approach production deployment and determine whether or not the platform is mature enough to address all of your use cases today, or if you require additional functionality coming in future versions. 

Thanks for reading Part 2 of this two part post. Stay tuned for the next installment, which will be all about assessing vRA8 workflow migration options, and go ahead and register for our December 10th webinar: Top vRA8 Deployment Considerations. Click here to sign up.