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.
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.
vRealize Automation veterans may still remember the migrations from vRA 5.x to 6.x and 6.x to 7.x. However, for many enterprises utilizing vRealize Automation, the migration from vRA 7.x to vRA 8.x will be your first major vRA migration. In an ideal world these migrations would only take a few clicks of the mouse. Migrating from vRA7.x to vRA8.x is going to be a lot like switching banks. Trying to figure out all the services that have your bank card on file for automatic billing and moving over automatic bill payments is tedious and time consuming. Which payments are monthly, quarterly, annually, and for how much? Wouldn’t it be nice if there were a simple tool to identify and update all the services that you have on auto-pay?
vRealize Automation is a lot like that. Whether it’s frequently deployed common workloads, special purpose blueprints that are used a few times a month, quarterly, or a handful or fewer times a year, or software customizations specific to vRA, you have to identify everything that will require hand-holding when you begin the migration from vRA7 to vRA8. The good news is that, unlike your bank, VMware does offer a migration assessment tool to help you determine if your blueprints are ready to be migrated from vRA7 to vRA8. As of this writing, we have not yet learned if the migration assessment tool will determine if your customizations and workloads are ready for migration.
Integrating Red Hat Ansible Tower with VMware vRealize Automation is a very popular enterprise automation solution. SovLabs has several excellent integrations that can help you accomplish and scale your integration of these two powerful cloud automation tools. This article is the first in a series of four articles covering the integration of Red Hat Ansible Tower with VMware vRealize Automation, based primarily on the content and discussion from our webinar with Red Hat Ansible on May 22.
Requesting a vRealize Automation deployment from Ansible. How, and why you would want to do it.
The SovLabs Ansible Tower Module for vRealize Automation with Static Inventory
The SovLabs Ansible Tower Module for vRealize Automation with Dynamic Inventory
The SovLabs Ansible Tower Plug-in for vRealize Automation CM Framework
Requesting a vRealize Automation deployment from Ansible
With Ansible Tower quickly growing in popularity, many developers and system administrators want to be able to utilize Ansible Tower to deploy infrastructure. This type of deployment is the subject of many debates within enterprise organizations, especially those with cloud teams trying to develop standards while enforcing policy and governance across organizations.
The good news is that organizations no longer have to choose between solutions. If you want to use Ansible to develop standards while enforcing policy and governance across organizations, now you can. Using the solution below you can request workloads from Ansible facilitated by vRA to enforce the desired standards and governance policies. Let’s take a look at how it works.
SovLabs has released it’s latest version of it’s vRealize Automation plugin version 2019.8.0. Among other key updated it is Certified for vRealize Automation 7.6 as well as ServiceNow Madrid. Below is the full list of updates available in this release:
Certified for vRA 7.6!
A new SovLabs 2019.x license key is needed in order to use the SovLabs 2019.x Plug-in
In Part 1 and Part 2 of this series, we created three inputs for our vRealize Automation blueprint: Production, WordPress, SOX compliance. These three inputs correspond to property groups that allow us to associate multiple custom properties to a single input. Using property groups allows us the ability to templatize how each input affects the outcome of a request. In this article, the Genie that we’ve previously released from the proverbial bottle is about to take form, as we walk through how these three inputs come together to determine the outcome of our request.
Let’s look at how the different input options impact the different modules.
In Part 1 of this series we walked through how you can use the SovLabs Property Toolkit and Template Engine to configure vRealize Automation (vRA) for our environment input. In this second part of the series, we’re going to walk through setting up the Application and Compliance inputs for our particular use case. If you are starting to see smoke, don’t be alarmed. It’s just our Genie being let out of the lamp.
In Part 1, we determined that the required options for our Application input will be:
Determine the Outcome
In this scenario, the selection of the application will have a significant impact on the outcome. However, while we need to think about the application, we also need to look at the larger picture. What do I mean by “the bigger picture”? Well, once we figure out the desired outcome for each of these items, we need to think about how each item relates to the environment and the choices we made in Part 1.
What if the requester chooses WordPress as the application and Production as the environment? Alternatively, what if they choose Microsoft SQL and Development? Will the outcome of the application differ based on the environment to which it is being deployed?
Some things to consider:
Do the workload specs change based on the environment selection?
Do development, test, and production instances have the same CPU and Memory requirements?
Do any of the integrations change based on application and environment?
Do WordPress and Microsoft SQL have the same backup requirements?
Does this requirement change based on which environment the workload is being deployed to?
Ever wish you were able to set more than one value from a single vRealize Automation (vRA) request input? Have you ever wished you could make some aspects of vRA more dynamic and flexible? Wish you could simplify the vRA request form? In this article I’m going to let the genie out of the bottle. All your wishes are about to come true. But before we summon our genie, let’s first dive into what it is that we are going to be wishing for. My wish is to have a simple vRA request page with only three inputs that can drive the outcome of every aspect of my request. Sounds too good to be true doesn’t it? We will find out soon enough.
Determine the needed Inputs
Determining what our inputs are going to be. For my scenario I need to the following three inputs:
The Environment (Production, Development, or Test)
The Application (WordPress or Microsoft SQL)
Compliance Needs (SOX or Non-SOX)
In my example, these are the only three items I need to know from the requester to build a server in my environment. The remaining info I can gather from the business group they belong to, what resources the workload is placed on, etc. I know every environment is different and many will require more than three inputs. Once you have read this entire 3-Part series, you will realize the number of inputs doesn’t matter. It’s how we use them that’s key.
Determine the outcome
What outcomes do we need to drive based on these inputs? Or, how will these help determine the outcome of the overall deployment? Will they influence items such as the machine hostname, Active Directory OU placement, vCenter Folder placement, vSphere tagging, application installation, etc?
About the Free Custom Hostname Extension for vRealize Automation
Here at SovLabs we are always helping our audience make the decision to either “build” or “buy”, when it comes to VMware automation solutions. Recently, we have been involved in some discussions about the free Infoblox plugin for vRealize Automation. Specifically,these discussions are around how the free Infoblox plugin for vRealize Automation handles custom host naming. That discussion prompted us to consider all such customizations and the support required when when they are integrated with vRealize Automation.
Custom Automation Considerations
There are a few issues at play here, including:
How do the different components of your solution work together?
Was it designed wholistically or were pieces added on as you needed them?
Did one source develop all of the components, or are they pulled piecemeal from multiple places?
If one source did all of the development – are they still available?
Who is supporting the development work going forward?
My six-year-old asked me to tell him a bedtime story and it went something like this.
Jimmy and Tommy are both vRA admins. Jimmy works for a large financial company and Tommy works for a large company that makes really cool stuff. Both Jimmy and Tommy made great decisions to use vRA to automate their private clouds. Jimmy decided his organization was going to build all their own integrations. Tommy decided to use the SovLabs plugin for all his organizations needs.
Four weeks after Tommy’s vRA deployment his company was using vRA to deploy 75% of their virtual deployments. Meanwhile after four weeks Jimmy is just getting started designing the first of many needed integrations. Fast forward a year and Tommy’s organization is now deploying 100% of their workloads. They have reduced management overhead by 45%, and are able to deploy new server requests in under an hour.
A year later Jimmy’s company is still working out bugs with their custom code. Their administrative overhead is up 55% and it still takes over two-weeks for new server requests to be fulfilled. Jimmy is working 80+ hours a week and perpetually stressed. Tommy on the other hand is working 30 hours a week, but don’t tell his boss. He is enjoying his job and has next to no stress.
I then ask my six-year-old who he would rather be Jimmy or Tommy? He responded neither daddy I would rather be you. I asked him why he said he wanted to be me. He responded, because daddy you helped Tommy only have to work 30 hours a week.