Viewpoints
If you have worked with vRealize Orchestrator (vRO) you might recognize that it comes with a learning curve. Depending on your background experience in IT, the learning curve differs. There are typically two viewpoints that can be identified: infra operations and developer.
In both cases you will need to get used to the constructs used in vRO to automate your tasks, Workflows and Actions.
When you are coming from an infra operations background, the learning curve will mainly be focused around getting used to writing reusable code. But when you are coming from a developer background, you are already used to writing reusable code. And the challenge is applying the best practices that you have learned while writing reusable code and apply these to vRO. Just to name a few: using source control, writing unit tests, having a text-file based project and being able to work in an Integrated Development Environment (IDE).
First investment
Starting out with vRO to customize and extend the capabilities of vRealize Automation (vRA) it begins with small to midsize workflows. In this stadium working with Actions and Workflows in vRO might feel convenient. Basically you are visually programming and when structuring this correctly, this gives a diagram-like overview with different steps grouped together that are executed from a workflow. The reusable pieces of code are nicely tucked away in Actions which are grouped in Modules. And with the use of Packages you can move your work between environments.
Growth over time
The challenge with visual programming starts to arise when more business logic is developed into the workflows and with changing use cases over time you need to make updates to how this business logic should behave. One of the reasons why visual programming is not as a ‘big thing’ like scripting languages are, is because making changes and keeping track of what happens, quickly becomes too complex and difficult to make changes without breaking something.
Now the environment is also subject to change and existing solutions get replaced with new solutions. Together leading to frequent updates and it does not stop there, because at the same time new features are added regularly.
If this is the case that implies the amount of engineers working on the content in vRO and vRA is proportionate and a release process is in place to promote these changes.
While there are some built-in functionalities that come with vRO to help with this, in my experience these rarely were sufficient to keep up with the agility of business and at the same time keep a steady velocity to progress without too many blocking factors.
Stay ahead
In order to stay successful in such an environment you will have to find a way to apply the development best practices known to software development. Now I’ve seen the situation where proprietary tools are built to help with this. Since both vRA and vRO come with an API there is some flexibility in doing so. But this adds a degree of complexity and ownership of such a tool and might not be something your organization planned to invest in.
Use vRealize Developer Tools
Luckily, internally at VMware they actively develop a solution that enables applying developer best practices in your environment. It consists of two separate components. A set of artifacts required to make the several life cycle stages of a project work locally on your system. These artifacts are bundled together and made available as a fling named vRealize Build Tools.
The other component is a Visual Studio Code (VSCode) extension that adds some useful tasks like scaffolding a new project and reading vRO content without having to leave the IDE (VSCode).
With both components in place you can develop from VSCode and use the terminal in VSCode to build, test and push content to vRA and vRO.
In a nutshell I mention these different life cycle steps of your project below to get an idea:
Build
Test
Push
With these possibilities building automation with vRA and vRO becomes more developer oriented and easier to apply best practices that have been existing for decades. This can help with improving visibilty of who does what and when. And increase the overall quality of the code that underlies the automation.
And because the tooling is built on top of Maven it comes with dependency management built in.
Implications
These benefits come with a cost, not necessarily something you can put a price on, but it means your organization needs to have additional tooling in place which require knowledge on how to operate, keep it running, up-to-date, etc.
It therefore is important to realize that when you are investing a lot in the customization of vRA and vRO you quickly become a DevOps shop. Which is already the case for large organizations but this can be a blind spot to recognize on the intersection of infrastructure operations en software development.
Some history and useful links:
A good read on some of the underlying ideas and benefits of using vRealize Developer Tools:
https://blogs.vmware.com/management/2018/11/automating-at-scale-with-vro-and-vra.html
Here you can read how it progressed by adopting the possibility to use TypeScript and the benefits it comes with:
https://blogs.vmware.com/management/2018/11/vro-development-with-typescript.html
The VSCode extension repository on GitHub:
https://github.com/vmware/vrealize-developer-tools
The VSCode extension in the marketplace:
https://marketplace.visualstudio.com/items?itemName=vmware-pscoe.vrealize-developer-tools
The vRealize Build Tools can be found with the VMware Flings:
https://flings.vmware.com/vrealize-build-tools