Products like vRealize Orchestrator work like a universal remote to orchestrate (integrate and automate) different types of datacenter services and software, reducing tasks that used to take days or even weeks down to a single click. And just about every web API in the world can be integrated and automated through REST or SOAP, this makes Orchestrator one of the most power tools out there. Attaching an Orchestrator instance to the vRealize Automation User Interface is easy, but once the tools are ready to use, how do we start developing workflows?

1) Conceptual Design and Readiness

  • Make sure all technical and operational staff are ready for collaboration, as a single workflow may integrate multiple technologies and departments/teams (Network, InfoSec, Servers, Active Directory, Backups, etc.). It’s not a bad idea to have a PM lead the charge.
  • Clearly identify the use case and the justification to the business. Define user experience.
  • Decide what the “trigger” will be, and how it be integrated and presented in the User Interface: Blueprint Provisioning Stub, Menu Action, Catalog Offering, etc.
  • Dedicate the resources for a lab or developer vRealize Orchestrator instance, with “rules of engagement” defined for all those using the product so no one will “step on the toes” of another. Having a common share to store packages, code, logs and documentation is recommended.

2) Technical Preparation and Development and Testing

  • Verify the accessibility of the API to clients like vRealize Orchestrator or FireFox RESTClient. This may require research online, downloading the white papers or API KB’s, and contacting the vendors’ development teams through a support call to work through any issues.
  • Identify all the CLI’s, OS shells, scripting languages, plugins, versions and coding tools needed and the technician’s that will be using them.
  • Gather the general number of actions and tasks each workflow will contain to scope the work. This usually starts with obtaining an authentication token. An Orchestrator plugin will establish a connection by configuring a static “host” or “endpoint” to a specific API, and use the token generated at the start of the workflow throughout. Some vendors have not yet designed their API in a way that is compatible, having tokens that expire or need to be refreshed with every API call or task.
  • Start with the simple actions and tasks that will keep the overall progress moving forward. A general engineer that works with the vendor’s API should be available to translate high level actions into each step of the workflow, working side-by-side with development.
  • Testing, testing and more testing. Make sure there is error checking, functionality, version history, QA, and security compliance as breaking operational silos and passing security guidelines will be required.

3) Publish in Production and Maintenance

  • All errors to this point have been resolved and documented
    The testing workflows that are ready to graduate in the lab Orchestrator can easily be transferred to production and folder organization in Orchestrator reflects the workflow use case – keep it nice and tidy as there may be hundreds of workflows in production within a few years’ time.
  • Verify in production with “all hands”, having a rollback scenario in place and making sure any issues that arise can be quickly addressed
  • Once officially in use or published, revisit workflows in regular cycles for any API improvements, version changes, updates, etc. – verify in lab then use in production.
Posted in IT Infrastructure Transformation