What is most valuable?
The ability to customize your own portal. We've gotten to the point now where we've used it to create this whole environment for users to be able to self-provision their own machines and get them into networks. We have a very large number of different networks, which means that many options of where they can put those VMs; their own environment.
How has it helped my organization?
We used to do everything manually. Up until just a few months ago, we used to have little reviews where, if they wanted a VM, they would come to us, tell us what they wanted, then someone on the team would actually submit the vRA form in an older version of vRA.
Now, the end user can go in and request what they want and do all that themselves, as long as they know enough about their application to get what they need. So, if you're just trying to add a couple of VMs or projects, where you know pretty well what you want, you don't have to spend days getting in line to talk about it, or worse, like back in the old days where you had to spend weeks waiting for someone to get it done.
What needs improvement?
Since I haven't been able to get as far into version 7, I haven't actually gotten into the guts of it, I don't know if this taking place already. But perhaps more blueprints of common tasks that are already there, so you have more of a place to start from. They may be there in 7, I haven't gotten a chance to look. It would need to have a base of, "Oh, I want to connect and build a VM and have these things," something to start from. Especially for people who don't have the teams that we've had working on it, they could get going quicker.
What do I think about the stability of the solution?
In the later versions, 6 and 7, it seems very stable. Really, it's nothing within the program itself that ever seems to cause the failures. It's some other component it's reaching out to which tends to have a problem, and that's not vRA at all. It's very good about telling you what's dead. It's usually more that the other application is having a fault and vRA tries to utilize it and gets an error back from the application, which then gets back to vRA.
It's not an even an integration problem. It's the application that it's going out to is not working properly. Then, it lets us know that it's not able to, for instance, connect to a Linux VM to the management product and register it. If it gets a failure there, it tells the folks who are managing the vRA. They tell us, and we go in. We check the management server. "Oh, it's not working. Well, let's go ahead and we need to restart it."
It's the same story on the other side with it connecting to AD. If for whatever reason, there's a problem with it connecting to AD, they'll go look at it. "Oh, this is the main controller having a problem."
What do I think about the scalability of the solution?
It seems to scale up pretty well. If you're talking about how many classes it manages, the older version, the 6.0 series, we actually have it managing all of our clusters across both of our major datacenters; we're talking about being able to build in to dozens of different clusters. So, it's scaled very well.
You can do quite a few at once. Usually, it's more the order of what it's getting back from an independent service. Sometimes, they can step on each other if you put too many off at once, but that has to do with the fact it's trying to request a sequence number; you're trying to get two sequences at once. But that's not really as problem with vRA. It's the way that it was setup to retrieve stuff from these other third parties.
How is customer service and technical support?
I haven't been the one that's had to call.
How was the initial setup?
Complex. Part of the reason it's complex is that it's like a blank slate. You have to go out there and make your own environments. It doesn't really do anything for you, so if you've got an idea of what you want to do, you have a path forward. But if you don't, if you're just sitting there looking at the blank screen, it could be daunting for some people.
We kind of knew what we wanted and it just took a while to get all those things setup. You have so many different components. Nothing within in our environment was simple, so every management product that we use was probably different than what anyone else would use. So getting all that to work, finding an interface that worked well, that was really why it became complex. It was the complexity of our environment behind it.
So it's not necessarily vRA, it's just that if you don't already have something that's out-of-the-box which says, "Oh, we do all these things..." (I'm harkening back to vCloud Director, because vCloud Director was an all-in-one that did everything).
What other advice do I have?
I think documentation and support are probably the most important things. If you don't care about documentation and support, you can grab a free one and try and build it. If you want someone who is going to be able to answer your questions, someone who's got the documentation already, so when you have a given error, they have it right on their webpage: "This is what this error means. Go do this." VMware's very good about that.
Overall, VMware is very good. It's very stable, very extensible, but it does have a relatively high learning curve. So folks that don't have the resources to dedicate to it may not be able to get very far. I do think it's a very good product, but it's very much a build-your-own product. That's good in other ways.
I would suggest people think about: "How much of this do you want to figure out yourself?" Because even within that process of building your own, you still have that layer of support. If you're looking at which one to pick, pick the one that's going to be able to provide you with advice. We've had professional services working with us on a lot of it at different points in getting it up and running. That's been a very nice driving force towards getting it to completion.