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.

I would rate my experience with the initial setup an eight out of ten, where one is difficult and ten is easy. It is straightforward. It's not that difficult. For anyone who was using this product for the first time, they need to go through the manual. I understand the dos and don'ts of it. But as an admin, if you have an experience of doing it, it's not it's not that difficult. It's easy to use.

Our customers require moving to public cloud adoption while upgrading their existing virtualized environment. There can be multiple use case scenarios based on which this decision can be made. The first could be if any workloads, servers, or applications are making the journey directly to the public cloud, and if it's a re-host candidate, then it has its own treatment plan. But the ones that stay on-premise have to have the workloads running on the latest VMware vSphere version for obvious reasons.

The recommendation, as an SI to the end customer, would be to go ahead and upgrade the VMware vSphere version to the latest 7.0 if you are not there yet.

However, it depends on multiple other factors. For example, you may be able to recommend that, but the servers/applications sitting on top of it should be able to support that as well. If that's not the case, then you'll have to make those delta changes in your servers/applications to ensure they support the upgraded underlying virtualized layer

The integration works well and there are plenty of out-of-the-box integration options available. While I haven't used all of them extensively, the integration experience is generally smooth and straightforward, typically requiring just one step for standard environments.

For the setup only, we need two or three days. But for configuration to edit a routine or test a routine, it can take anywhere from maybe one to two weeks.

So, two to three days for setup and then one to two weeks for deployment.

vRA 8 is normally managed by a single guy.

The setup needs coding. It's not easy. It's not straightforward. With the newest releases that we have ahead, we need someone who is good with the YAML codes. 

Now, there has been improvement. Previously, we should have a person who really knows Java, Python, and other codes that are being used. 

But for the recent release, we want one who should understand codes, one who should know how to, and one who should have knowledge about how to do REST API calls if we want to integrate different components with VRA. 

So, programming knowledge is a must when you're using VRA. The most tedious task will be to configure the VRA. Installation is easy; you can do it. 

However, configuring VRA with the whole of your setup within the data center is not easy. It will take some effort, and it has to be done right.

The deployment process is not fast. It will be time-consuming. A few of the modules are already there, but it is time-consuming. Moreover, it depends on the sort of integrations we want to do. If we want to integrate 15 components, different components with vRA for end-to-end provisioning, it will be consuming.

We implemented the solution in-house. 

Our in-house team was responsible for deployment. We have some VMware experts in the organization. Approximately five people are required for deployment and maintenance. There is a support engineer, a solution architect, and we are responsible for the level-three support.

In our organization, we have five people who are dealing with VMware infrastructure. Our senior solutions architect has different kinds of certification in VMware solutions. There are two senior engineers and two junior engineers reporting to him. So, we have a team of five people for our internal management and external deployments.

We need an experienced team to maintain the solution.

We deployed the solution ourselves.

The product as a whole was offered by Dell EMC but we used VMware as an integrator and for the setup. We still have some VMware specialists working within our team.

For the initial setup, there were four people from my organization involved:

• One SME from compute and storage
• One SME from network
• One SME from application
  
• One technical project manager.

We actually used a lot of VMware services because we didn't want it sitting in the box too long. We had them come in, then they had it up and running in two days. There was a lot of tweaking to do, but it was up and running in two days.

We integrated in-house. 

We used a service to implement. We did our research and now we have a good guy from VMware services. We plan to keep him. If we always have new people coming into deployment services it can take at least five days to teach them how the system works and to do all of the certifications needed. Our plan is to stick with this guy from VMware services. 

We implemented a majority of the service internally and only reach out to the vendors developers prior to making changes in the design that could impact rework to correct bottle knocks and development dead ends. 

It was implemented by VMware professional services with an excellent level of expertise.

Six people from our company were involved in setting up vRA.

We have a VMware PSO at work who is very good. He was experienced and had good knowledge so we were very happy. We are very enthusiastic to continue with VMware in the future.

Sometimes we need to get help from VMware consultants. They help us to upgrade the infrastructure and fix issues that we can't fix on our own. They are very helpful and we've had a very good experience with the VMware consultants. We don't use them all the time because we have our onsite engineers who integrate the product. For the mission critical stuff, we use consultants from VMware. Our interactions with VMware consultants is one of the best experiences with this solution. This is something I benefit the most from.

We constantly do upgrades, once they are released, and we have found them to be very straightforward, I cannot complain at all. From our side, it's more difficult because we have customers who are our clients so we need to schedule all the maintenance windows with them. We also need to ensure after the upgrade that everything is properly tested. But these are mostly problems that come from serving big enterprises which have their own policies. But upgrading the product itself is very straightforward and we never get any serious problems.

We implemented in-house. 

An in-house team.

We did the deployment of the test environment.

I worked with the UK partner to set up the 7.3 version. The upgrade process 6.x to 7.3 was a significant effort. I'm hoping that 7.3 to the next version is much smoother.

We deployed it ourselves.

We did it on our own.

We did the integration directly through VMware.

I spent about a month working on the set up. It was pretty complex. 

It takes a smart person well-versed in anything from JavaScript to building out blueprints to somebody who knows vCenter and vSphere. 

To deploy it, we brought in a consulting company because were strapped for user availability to set it up. Therefore, having a consulting company sped up the process of putting it together.

I had a consultant help me a little bit. I did most of the work myself because I like owning the products.

There were about 10 of us involved in the setup. We have just a cloud team.

I am the integrator. I do the deployment for our customers. 

We used a reseller for the deployment who was great.

In the first deployment, they sent an in-house team.

We used a consultant from VMware for the deployment.