Blog
21 April, 2024
Before vRA came around, when a developer needed a virtual machine on which to apply and test his code, he or she would open an IT ticket using a ticketing system and request to provision a VM using a particular operating system, certain resources, etc. The request would often be reviewed for approval by management to ensure that the necessary resources were available, no quotas were exceeded, etc. vRA from VMware is a Private Cloud Platform that automates this process, allowing IT teams to offload this manual work into a workflow and making the experience smoother and more precise while still providing the needed capabilities to the end users.
What is the difference between vRA 7 and vRA 8?
vRA 8 marks a totally new era for the solution. vRA has been around for several generations and has a long history of changes and upgrades, which were beginning to make it heavy and complex. In an effort to improve the service, VMware decided to provide the same key features but tackle them from a completely new, cloud-agnostic direction.
Instead of simply provisioning virtual machines, which was the core of vRA7, in vRA 8, we can provision and manage almost any object without being limited to VMs or the VMware ecosystem. vRA 8 enables integration with Amazon, Google, Azure, and more – in other words, not only on-prem but also to multiple public clouds and various solutions.
What are the advantages of the new approach? They are many and varied:
• API-first approach to deliver cloud automation
• Deliver Infrastructure-as-Code using a declarative YAML syntax
• Iterative development of blueprints
• Cloud Agnostic Blueprints
• Native Git Integration
• Faster and Easier to maintain
• Built on modern platform using Kubernetes-based micro-services architecture
• Much easier to integrate into various systems than vRA 7 had to offer
• Built-in pipelines in Codestream
• Ansible integration
• Better resources pricing using vROPS integration
• Improved integration for VMware products in the vRealize suite, like vRLI
• Improved extensibility using multiple languages using ABX solution
How do you migrate a client from vRA 7 to vRA 8?
VMware offers a migration solution from vRA7 to vRA8, but it often isn’t sufficient on its own because of the many changes between the versions.
As I mentioned, in vRA 8, the VM is no longer the center of the cloud template, and it isn’t how we define the templates of what the users are provisioning; instead, we can now provision to multi-clouds by constraints. Because of this, we recommend not to simply convert a vRA 7 blueprint into a cloud template since the logic is not the same.
Instead, the key is to understand what the client needs to achieve – what they need to do, not what they’re already doing – and to translate the blueprints to the vRA 8 approach in a way that keeps the client running smoothly and preserves (and where possible, improves) all of the same features from one version to the next.
To achieve this, the first step is to map the client’s entire vRA 7 environment, detailing every user that connects, what permissions they have defined, which services and catalog items they are assigned to, all of their privileges on vRA 7, their existing vRA 7 workloads, etc.
Next, we need to understand which custom automation runs on their environment, the properties that affect the provision processes, and which applications will be installed during the provisioning processes. During this step, we will suggest using native integrations that vRA8 has to offer and use it.
Of course, if the customer has thousands of blueprints that need to be migrated, the processes must be automated. vRA8 is built using an API-first approach so that everything on the user interface can be easily done through Rest-API. For this reason, we developed our own custom automation to support us during this process of the blueprint migration.
The client inputs each blueprint name from vRA 7, and the automation reads the structure of the blueprint and identifies things that could not be done through VMware Migration Assistant, for example – for example, NAT objects or unique custom properties that the customer is using.
In my last migration project, the customer used “promiscuous mode” to support his deployments. This automation was fitted to vRA 8 with NSX-T, noted any custom properties and automation, and translated the blueprint to the vRA 8 Cloud Template efficiently, without any typos or errors along the way. Unfortunately, NSX-T does not support “Promiscuous Mode” anymore, so we had to translate it later into a Portmore session. This could only be done with a deep understanding of the customer environment in advance.
What is the key to success with vRA 8?
Like any successful project, you have to begin with good design – not only in partnership with the client’s IT department but also with the end users. Good design requires a deep understanding of the infrastructure you are working on, the integrations you’ll be using, and the application behavior, as well as a creative approach to custom automations. The better we research and learn about what is native in vRA, how it works, how the customer needs to use it, and what products and APIs need to be integrated, the more successful our outcomes will be.
Written by: Adiel Gilboa, Hybrid Cloud, and Automation Solution Architect