Nutanix Cloud Manager Self-Service alternatives and competitors

I'm not a decision-maker at my current firm. It is a huge company called Allianz Technology. We have vRealize deployed, and I'm part of the administration team. We manage our infrastructure and compute storage as well as the virtualization part with vRA.

We have a lot of internal customers and entities of Allianz whom we treat as customers. They make use of the internal cloud portal to spin up VMs and manage them.

Our vRA 8.0 is a distributed deployment in Europe, the US, and Australia.

vRA has helped almost every team. For example, it has helped the development team and our training team.

We are using vRealize Orchestrator (vRO).

vRA helps automate deployment for developers. We do a lot of orchestration or customization within our environment so it will suit each of our customers. So, we have different business units who have their own templates. Some customers might choose a backup solution, then some others will be choosing another one. All of these have been orchestrated. 

Some customers will also opt for a disaster recovery (DR) solution. If they choose the disaster recovery service during the deployment of the VM, then a DR solution will be offered to them and a VM will be created on our DR site. Everything will be synced through the VMware service.

This solution has made it very simple for developers. In a way, a layman or NOC guy can deploy a VM. Once they are familiar with the offerings, they can just deploy it without knowing what is going on in the back-end.

We are migrating from vRA version 7 to 8, but the migration is really hectic and time-consuming. There are no straightforward paths to migrate. We are doing an entirely new deployment to go to vRA version 8.0, then somehow get all of the VMs to vRA 8.0. Therefore, it would have been great if VMware had some solutions to upgrade from vRA 7 to 8 seamlessly. This includes the management of all the objects or VMs from the older version. Unfortunately, it is not there.

We have been using vRA for more than three years. Previously, we were on vRA 7.4. Currently, we are operating everything in vRA 8.0. We have been migrating our entire managed VMs and everything to vRA 8.0, which is an ongoing process.

vRA has been pretty stable, unlike vSphere infrastructure. With vSphere, while nothing has happened, there are a number of integrations that could break. However, on the vRA front, it has been good and stable. There hasn't been a single situation where we have run into a big issue and had an outage, which is great. 

It is too early to come to a conclusion on vRA 8 because it is still getting migrated, but the initial impression is good. It is better than vRA 7.

vRA 8 is really scalable. There are a lot of integrations that have been much easier compared to vRA 7. For example, Orchestrator is now built into vRA rather than being a Java-based application, like it was in vRA 7, which has been good.

In our organization, there are around 20,000 to 30,000 users. These could be project managers, application owners, etc.

Their technical support is good. Whenever we have had issues, the VMware support team was spot on, especially with vRA. However, this has not been the case so much with their other solutions, especially like vROps, where we had been having issues for a couple of months without any actual fixes.

At my previous firm, I worked with vCloud Automation Center (vCAC). vCAC only evolved into the vRA later on. While primitive, it was stable and good to use, though not very customizable.

vRA was the first solution of this type for my current organization.

vRA version 7 was very complex to set up. vRA version 8 is pretty straightforward, whereas version 7 was very complex. It could have been better, but they are on the right path with things.

It has been a very major upgrade. We are doing a lot of other customizations and a strategy session, along with this vRA 8 migration, bringing all our storage solutions to a single vendor. All of this is happening in the background. Earlier, we had a different backup solution for different locations, like APAC and the US. That is why it is taking a very long time to do our migration to vRA 8.

This vRA 8 migration is just one part. There are any number of other things that are coming together with this vRA 8 upgrade. So, it has been complex and happening for over two months. We are hoping to combat it by next month.

We have an internal architecture team. They decide how a deployment should go at a high level. Once the decision is made, only then we will implement it. They considered options, like there should be a single portal for global customers' entry within Allianz. Whenever they choose a location within the portal, the request should go to that location. That is why they went for a single distributed deployment this time. Earlier, it was an entirely different instance for each location, which was totally not connected in any way.

Now, it's a distributed deployment, which means if a customer logins in using a single portal. They just use the drop-down location for wherever they want the VMs to be, then the request will go towards the deployment of that location and dispatch properly on the front-end. 

We have our own DevOps team who does all the orchestration, integration, and whatever other integrations that we want to do. We will check with the vendor of that application, along with VMware, then plan accordingly. We have a lot of integrations with applications, like Brokerage and ServiceNow.

We need 10 to 15 staff members for deployment and maintenance. We need an architect, an engineering team to do all the customizations, a monitoring team, a DevOps team, and a support team for any post-deployment support of vRA.

vRA's automated processes have reduced infrastructure provisioning time. Whenever a customer builds a VM, they can choose the number of instances. They can just click the drop-down, select the number of instances, and that many VMs will be deployed in a single go. This has been great because previously they were afraid of doing it manually. Now, every time the technical team needs to deploy, they can provide all the parameters. Its automated processes have brought down the overall time to a fourth or fifth from our previous manual deployment's time.

This is just for supporting our internal needs for all our internal customers. So, we don't actually make any money from this cloud offering.

We evaluated Cisco ONE Cloud and Nutanix Calm. We were using VMware solutions in the past. We received good feedback about vRA and that is why we went for it.

Cisco had a lot of limitations on its networking. They needed their own virtual piece rather than any generic or VMware-default distributed switch. That was a major limitation. For the Cisco switch, they own the hardware layer so you need Cisco Unified Computing System (UCS). Cisco UCS doesn't have that much of a customer base, so the development would be slow and have even buggier fixes. Any release for bug fixes or patches would take time

There are different AWS and Azure services, but these are not connected with our vRA as of now. In future, we will maybe look for some type of hybrid setup.

For applications, we are still provisioning the manual way after deployment. We have included some of the basic applications into our blueprints. So, they will get deployed along with the VM spin-up. If we haven't integrated the application centrally, then it is because we didn't get the customer approval because they felt like some customizations may need to be done during each deployment of the application. Therefore, they didn't agree to the integration of applications into the blueprints.

We are trying to onboard other internal customers into our vRA. We have been onboarding customers even onto vRA 7. So, it is a never-ending process because it is a huge company.

I would rate this product as a nine out of 10.