In vRA7, there are a number of components that come together to make the magic happen. Each component plays a vital role in how you design, build, and invoke your customizations.
The event broker was introduced in vRA7 to make it easier to trigger the workflow stubs that existed within the IaaS server. These stubs were always there, but only a handful were accessible and they were not easy to configure. The Event Broker also introduced a more granular way to decide when a workflow should or should not be executed. Although the event broker has dozens of events you could subscribe to the following were the most commonly used:
Many of these states included a pre and a post execution allowing you to decide if you wanted to execute your workflow before of after vRA’s execution of that state. These states that are the core of vRA7 extensibility no longer exist in vRA8. vRA8 is a completely new platform, written from the ground up, and no longer includes the IaaS host that controlled all of these states in vRA7.
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.
Many of us have been eager to get our hands on vRealize Automation 8 (vRA8) for some time now. If any of you are like me, you may have dabbled in the Hands On Labs with vRealize Automation Cloud (formerly CAS) for the past year. But, without having the capability or the requisite login for the service, you kept abreast of any updates coming out of the vRAC camp. I have been through quite a few versions, upgrades, migrations and code changes in my time working with the vRealize products. Most of this experience was spent in architecture, engineering, and development at a large enterprise customer, where we had to carefully navigate each of these changes. This article covers some of my first impressions of vRA8 as an advanced user of the product since the early days, circa vRA6.
There is a lot to cover here. The product has been re-written from the ground up. The Cafe and IaaS nodes that we are all familiar with are now gone. Custom workflows will most likely have to be completely re-written. Migrations will have to be planned and extensive testing required prior to any production deployment. It will likely take the better part of the next year for the community to get a handle on the new product. However, if you’re reading this blog post, you are probably actively engaged in working with vRA in some fashion, and you’re excited to see the new capabilities offered in vRA8.x.
The following is a two-part summary of some of the very high level aspects of the new system that have jumped out at me in the first 2-3 weeks of working with VMware’s reconstructed code for vRealize Automation. In part one, I explain my experience working with the Documentation of vRA8 and Tagging, the new way to manage your machine metadata. Part 2 will cover my take on ABX and Policies. Also, we’re going in depth on these and other topics in our December 10th webinar: Top vRA8 Deployment Considerations. Click here to sign up.