VMware vRealize Automation (vRA) Review

Enables us to flex up or flex down the environment quickly; makes our DevOps processes more consistent


What is our primary use case?

Our primary use cases are around deployments supporting DevOps, around service provisioning of IP addresses, DNS; self-service entitlement or enablement. And then, driving some workflow processes from our service marketplace, through automation, to actually have them execute within the infrastructure.

It's performing pretty well.

How has it helped my organization?

Speed to market. It helps us to improve the rate at which we deploy and the consistency in which we deploy. It has allowed us to scale up and scale down very quickly.

As we meet our open enrollment periods and then we come off of those enrollment periods and go into a normal operational state, we now have that ability to flex down that environment or flex up the environment quickly.

Another side of the coin is the supporting of DevOps. Now, with the advent of the automation, we've been able to give DevOps the ability to spin up environments, give them lease times, and then have it automatically reclaim the environment. So we can build workflows around DevOps processes that are more consistent. Our past configuration was that they would spin up whole DevOps environments of full, physical machines and they would run indefinitely. That was "Bob's" Dev environment and then "Joe" would come and say, "I want one." And then we'd have all these environments. Now, I can give him his environment for 48 hours and I can take it away and he can spin up another one. Or I can archive it. It allows us to be a little bit more agile.

What is most valuable?

The most valuable feature is the consistency it delivers, at the end of the day. We know that we have consistent images based off consistent Blueprints, check-pointed or QA'ed in a consistent manner.

What needs improvement?

It is not super-intuitive. It does require some skills to understand how to use it. I had no problem, but I had spent a lot of time already learning this product ahead of moving it to an operational status. But as we did so, we had a hard time bringing some people from other groups into the fold, to script and work against this environment. So, the ability to build workflows within that automation needs to be streamlined.

In terms of additional features, I would like it to be able to poll my vCenter infrastructure more rapidly and adapt to changes quickly. It should alert me and let me know when there are broken components, as a result of underlying infrastructure changes. It needs to be more stringent.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

It is very stable. I've had no downtime from the vRealize Automation appliances or components. I think the biggest challenge is being communicative in the infrastructure as you change the infrastructure underneath the automation. This goes back to the naming conventions and the consistency, but you need to be cognizant, as you change your underlying infrastructure - whether that is new storage arrays you're adding, new DV switches you're creating, or new hosts that you're taking out or putting in - you have to be cognizant of your automation.

It would be nice if this product was a little bit more intuitive regarding what's connected to it.

What do I think about the scalability of the solution?

We could scale horizontally with Automation but we're looking more at containers to scale some of our apps more horizontally. But yes, it does integrate very well with other vSphere products that allow us to scale horizontally as well.

How is customer service and technical support?

The technical support is very good. I've actually been able to turn over my operations to use technical support. They can actually walk me through the problems within the product. That has been great because I tend to focus more on infrastructure or the underlying components, so for the code components, the support is great.

Which solutions did we use previously?

We were manually spinning up clone templates and building them.

We recently took over and built our IT after 50 years of being under HPE. About five years ago we decided to internalize our IT and take everything back. We built a new IT organization literally, out of this solution; it is one of the tools that made us successful. Once we virtualized our infrastructure, automation is what made us be able to work with it.

Our important criteria when looking at any vendor are support and communication.

How was the initial setup?

I was involved in the initial setup and the PoC. It was very complex on the initial setup because we started with the 6.x version and eventually migrated to 7. The way it was architected, with the Orchestrator being outside of the vRA appliance, was difficult to set up and configure. The next versions made it a much more straightforward configuration.

We did not do an upgrade. We did a parallel build. Several upgrades actually blew up and failed and destroyed the environments, so we gave up attempting to upgrade a 6.x environment and built a brand new 7.x. At the time, we did not have Code Stream so we could not laterally migrate. An important component of this is Code Stream. For the ability to scale and have multiple automation instances, Code Stream is essential to be able to move that back and forth. If you already have an existing automation environment, you should look at Code Stream very heavily, rather than redevelop.

What was our ROI?

We have seen quite a bit of return on our investment. We've actually been able to really change the way that we're doing build and deployments of virtual machines. We've reorganized around that capability. At one time we had a dedicated build team, separate from Windows and LS teams. Now, we've integrated them together because those teams are actually spinning up and building their own VMs right out of Automation.

Which other solutions did I evaluate?

We did look at some automation around the Red Hat stack itself. Our environment tends to be larger on the Linux side than it is on the Windows side, the Microsoft side. So we did give some consideration to maybe automating through Ansible and some other processes. But because of the simplicity of development, relative to the other options, we chose vRA. We also chose it because of the integration with our vCenter. We wanted to be under vRealize. We wanted to be one consistent stack, whether it's monitoring, spinning up, security, or containers. We want to try to keep everything under one platform.

What other advice do I have?

I would definitely recommend vRealize Automation.

One thing that we've had to realize about this product is, it's dependent on some back-work that you do inside your vSphere environment to prepare for it: things like tags, things like folders, things like naming conventions. We've discovered that these are very important when you're attempting to roll out this product because you already have an established vCenter environment. For instance, in our case, where we had multiple data centers, we may have had different implementation times and perhaps may not have had the same standards around things like naming conventions, DV switches, or storage. Because they map, you have to very cognizant of that.

That's been an issue, not only on the Automation side but across the whole vRealize Suite. I also manage all of the vROps, the analytics, and the integration between the analytics, the vCenter, and the Automation.

It can be tricky. You need to be detail-oriented on how you configure and set up your vCenter so that you're consistent in all implementations. If you have a multi-vCenter environment, you want to make sure you use the same naming conventions across them.

We already had established standards, but as new people came on board, they may have varied something thinking, "Oh, I can just shorten this," or "I'll hyphenate this VLAN_, no, actually I'll do a VLAN-". When you go to map that, to automate that, and you go to read your available VLANs, suddenly it doesn't recognize them because you're not consistent in your conventions. That's one thing we really discovered in automation.

The second was using naming conventions that are consistent and searchable so that you can understand different applications and environments. That's going to be very important when you're actually building automation and workflows.

It's something that the customer needs to be cognizant of and vigilant about as they move towards automation. Automation is taking the existing infrastructure and attempting to automate it and use it and leverage it in a way that's dependable and consistent. I think that's the greatest thing we get out of Automation. It isn't speed, it's consistency; consistency in deployment, consistency in execution.

I give the solution a nine out of 10, based on my satisfaction with the product. My experience with its growth over time - the last few versions I've looked at, 7.3 to 7.4 - is that it is going to give us some capabilities in integration that we didn't have before.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Add a Comment
Guest
Sign Up with Email