Managing Request Pipelines

Written By Nathan Bennett

As business diversifies we find ourselves in a bit of a pickle. Our operations teams that work around the clock have to deal with more variations of work and at a shorter amount of time. Requests from your ticketing solution comes in for development resources or adjustments, to full production releases and builds. These workloads take days and weeks and moving in agility has become more tedious and slow then the word “agility” would grant.

How can a company of thousands allow their engineers to successfully complete request in a timely and accurate manner? One solution that we will look into together, is vRealize Automation.

By utilizing the access management of Active directory, or the internal tenant management in vRealize you can now allow your engineers to create automation and publish it directly to the customers. This bypasses the engineers wholly by allowing the needed day-to-day to be performed and completed via the tool itself, and the engineers are never taken from other duties. Lets take a look at how this solution will play out for a business.

In vRealize Automation you create a target location known as an “Endpoint” to pass payloads to. Once these endpoints are created the payloads that you pass, as well as connecting one payload to another, becomes the web that interconnects infrastructure, security, standardization, and automation all in one location. This is the basis of vRealize Automation. So, the first “Endpoint” you would create would be Active Directory. Thus syncing your tool into the groups and users that are already created there and bringing them into the tools management.

vRealize Automation uses a middle component known as the Identity Manager or the “IDM”. The IDM is either embedded into the appliance or utilized as an external solution. vRealize Automation connects to the IDM and syncs the needed users and groups to the individual business groups or projects.

Now that we have them in the tool and they are synced, the solution uses what are known as “Projects” to keep those groups separated. This will allow your AWS developers access to those accounts, while the on-prem users can utilize requests for their vSphere solutions. By doing this Jim in AWS-DEV can see all the needed blueprints that have been created and standardized in AWS, but Jill in Production Support, can only see the resources in vSphere that allow her to help her customers quickly.

The end result, is that you have successfully created a self-service portal that will allow your users to request they daily, weekly, or so on, needs of the company at speeds faster than an engineer with a checklist can provide. The engineers are also happy as this tool provides them a way to expand their abilities, while helping them move forward to newer and better solutions, or simply expanding and growing the business.

Share the Post: