The new vRealize Automation 7 LifeCycle Extensibility is probably one of the most impressive and powerful new features. LifeCycle Extensibility is an Event Broker Service which enables providers to register and manage events, producers and consumers. You can now use the out-of-the box extensibility, by plugging new functionality without the necessity to change the existing services codebase.
With vRealize Automation 6.x you had the possibility to inject custom logic at various predetermined IaaS life cycle stages by leveraging IaaS state change workflows, known as workflow stubs. You could use the workflow stubs to call out to vRealize Orchestrator for bi-directional integration with external management systems.
In vRealize Automation we have the following stubs to interact with:
- BuildingMachine (WFStubBuildingMachine).
- RegisterMachine (WFStubMachineRegistered).
- MachineProvisioned (WFStubMachineProvisioned).
- Expired (WFStubMachineExpired).
- UnprovisionMachine (WFStubUnprovisionMachine).
- Disposing (WFStubMachineDisposing).
So there were only six stubs to interact with during the lifecycle of a provisioned blueprint.
Event Broker
vRealize Automation 7 LifeCycle Extensibility aka the Event Broker provides an intuitive user interface for tenant- or system administrators to subscribe to events which than activate customised workflows. So instead of the previous six stubs we can now interact during the complete lifecycle based on the events received on the RabbitMQ-based message bus. You can even make the subscription conditional, so eg. start a workflow when all virtual machines with names starting with ‘TEST_’ change their power state to ‘PoweredON”.
Examples of some LifeCycle Extensibility use cases are:
- Customize machine naming.
- Change machine configuration during provisioning.
- Number of CPUs.
- RAM.
- Disk.
- Customization on different levels of provisioning.
- Endpoints.
- Reservations.
- Blueprints.
- Extend approval policy with external system.
- Notify external system on any configuration changing.
So instead of having a limited set of workflow stubs, we can now create policies that define when to kickoff a workflow. There are sixty+ different lifecycle events to which you can attach workflows at pre-, during- or post-event.
This makes vRealize Automation 7 so much more extensible than what it currently is. The possibilities are limited by your imagination. Another great benefit is that the extensibility is no longer part of the workflow. This means you can provide an application architect with the Workflow Designer and let them create the integrations needed to make sure an IPAM or CMDB workflow is kicked off with each deployment.