What you're asking would require a huge response, but I'll just say there are enormous differences between vRA and Terraform. The biggest one that matters to enterprises is the control, security, auditability, and governance controls that vRA brings. Not to mention the frameworks that vRA has set up that you have to very carefully piece together in Terraform. They both have their uses and so it's really an apples vs oranges type of discussion.
I work for a large financial institution.
We we are also in a situation where our dev ops teams are saying that they we should get rid of VRA and replace it with Terraform because it can do everything that VRA does. They are also selling this to our Exco team and I’m battling to find reasons or answers on where the one would’ve be better to run vs the other or how they would compliment each other. Could you not maybe assist me with some more concrete or solid information that I can use to justify why we should use both or even stick with VRA. Even if you mail me directly.
Coincidentally, my context is a large financial institution too. Separation of duties, and therefore access, drives a lot of technical issues.
Did you ever get an answer or more information?
Going through a similar discussion over here.
Very early stages.
First thing that comes to mind is what is the size of your development team, and how familiar are they with Infrastructure or Infrastructure as code.
Some developers on our team had difficulty with infrastructure concepts at the beginning, so there will be a learning curve.
There are many Gartner client reviews on Terraform, and the general advice is to go with Terraform Enterprise vs. the free edition.
So if management is doing a cost benefit analysis they will need to start there.
Retraining staff, and investing in a Cloud Management Platform, changing business process, also come to mind.
The vRA benefits daphnissov pointed out, are also areas you should focus on in your analysis.
That's all I have...
We are also in very early stages about replacing vRA with possible Terraform. But probably not in the same matter.
As a solution we require the users (developers+Support) to have no understanding of IaaS, they only want their machines/databases etc with a touch of a button. Also we have no public cloud (AWS/Azure etc). Futher more we basically use vRA as a frontend for deploying and assigning IP's. (Everthing is done in vRO worfklows based on user selection in vRA)
The trouble we see ahead is vRA 8.0. It's the second time VMware breaks almost everything (vRA 6.x to 7.x was the first). We have spend alot of time developing vRO workflows witch needs to be redesigned. And vRA 7.x will go out of support in a little over a year. (This you really need to consider, if you you want to go with Terraform and vRA 7.x!)
So we are are looking into the following solutions at the moment:
1. Replace vRA with vCD and (possibly) Terraform (keep using vRO)
Much more expenisive solution, however this mean we can keep alot of the vRO workflows. We can use vCD as frontend and it's more flexible than vRA. Futhermore it should be able to give us addition features when it comes to vRO (RabbitMQ/vCD can trigger alot more events than vRA/EventBroker). It will also prove true multitenancy (not the "fake" one vRA has.)
2. Create everything again in vRA 8.0
Alot of work, and we have no idea what will happend with vRA 9.0, experience tells us it will not be compatible...)
3. Going with Foreman/Ansible
Loses alot of features, alot to redo, but cheaper.
4. Finding another product (Resolve, BMC, Hiro etc).
So far we have not decided, but we are doing PoC on Soltion #1 and #3.
Just one point of correction to make:
And vRA 7.x will go out of support in a little over a year.
At this time, based on the Product Lifecycle Matrix document, vRA 7.6 will be supported until April of 2022.
Tons of differences, Key points for me are the following(Below is for vRA 7.6):
1. Terraform requires a pipeline and other considerations to deploy managed machines. These also require understanding and advancement in DevOps for the organization responsible and the users.
2. Terraform is much easier to solve run-once solutions(config scripts) and multi-cloud deployments than vRA(My Opinion).
3. Terraform does not have a front end so that solution is needed(Maybe Terraform Cloud, or Enterprise does, but last I saw no)
4. Terraform has no governance, or budgeting so you would have to make those settings within the perspective cloud providers.
5. vRA has a built in orchestrator for XaaS automation that expands beyond IaaS deployments
6. vRA has a front end catalog that allows segregation of users allowing Business groups to view certain services and others to see their own.
7. vRA is Endpoint automation that can connect with multiple solutions including a majority of api's, Powershell, SSH(etc)
8. vRealize Suite has budgeting solutions to track and pull cost(depending on your licensing and version)
This is, of course, coming from a vRA admin. However, I've used Terraform for a couple deployments, and I gotta say its a much stronger solution for public cloud deployments, HOWEVER, with vRA 8 now, its a much fairer fight. 8 can build cloud "agnostic" machines and Terraform cannot. This allows us to build a blueprint for a machine and build it in Azure or in AWS exactly the same as we created it. Pretty neat.
I have experience the same thing where some vRA+vRO developers are not familiar with infrastructure, e.g. what is a port group. Further complicating the matter is unreliable endpoints, e.g. vSphere, NSX, config management solution, IPAM, etc. Everything works fine in the lab but by the time we get to production endpoints get busy or go offline or are put into maintenance mode without notice. Building resiliency into to both vRA+vRO as well as the code has been a real challenge. I'm wondering how Terraform deals with this better/worse/same/different?
I'll keep in mind enterprise vs. free Terraform. Not sure what is being used by the client.
Thanks for your input.
My client has accepted that going from vRA 7 to vRA 8 may introduce a lot of re-engineering owing to how much was learned the first time around. They implemented vRA 7.3 in just three months which considering the size of the environment and the complexity of the customization done (VMware PSO didn't arrive onsite until late due to vendor management processes) is, without exaggeration, miraculous. Thankfully the recognize that a lot of mistakes were made and if had the opportunity to re-do it would do things differently, hence the open mindedness in going to vRA 8.
Your comments about vCD +vRO are interesting. What is the more flexibility you mention with regards to vCD? I remember having similar conversations with someone from VMware PSO back in the vCAC 5.x early 6.x days.
I agree about your statement about VMware breaking (seemingly) everything with each new major release. In the case of vRA 8 it is a welcome break from the old Dynamic Ops code. However there is a lot missing from vRA 8.0. That being said we are in the early days of assessing the transition from vRA 7 to vRA 8 and my estimate is that almost half of the customization done will go poof with the new capabilities being introduced. Something as simple as being able to create NSX security groups with deterministic names (not pseudo random) required a lot of customization as did the need to better control placement logic.
I'm curious to see/hear where you go with this.
Your point about DevOps (someone else mentioned this too) is what I suspect is driving a lot of the conversation towards Terraform. The sense I have is that Terraform better allows one-off blueprints, not so easy in vRA+vRO. From my limited experience a lack of GUI for developers is a non-issue. They typically want to put their configuration into a file -- makes it easier to adjust/edit and re-submit. The VMware CloudClient is really klunky for this kind of thing and there are better ways of doing this (PowerCLI vs CloudClient ).
There still remains the issue of separation and delegation of duties with regards to content. For example, my client has separate teams for Windows engineering, Linux engineering, database engineering, middle ware engineering and so on. vRA + vRO 7.x doesn't provide a good, clean model for allowing these teams to collaborate on blueprints. This mostly has to do with the amount of customization required in vRO. vRO has a very steep learning curve and doesn't provide a good way to keep the different groups from trampling over each other's work.