Blog
        

December 18, 2022

Upgrading to vRA 8 to Streamline and Simplify Self-Service Cloud Deployment

One Company, Many Advantages

 

VMware vRA (vRealize Automation) is an incredible automation platform that delivers self-service clouds, multi-cloud automation with governance, and DevOps-based infrastructure management and security. At TeraSky, our team has implemented vRA for many customers for various use cases. These use cases can help others understand how vRA can be helpful and under what circumstances.

 

A returning TeraSky client is a customer engagement company that provides a platform to help users derive greater value from their technology investments through AI, analytics, and open integration. This company’s clients frequently requested deployments to test different versions of their products. In fact, there were, on average, 300 of these requests every day.

 

Our client was managing these deployments using vRA 7, a static environment with static, non-changing IP addresses that were provisioning deployments under an NSX-V bubble network – a “one to many” NAT network in which they had one public IP address for several internal IPs. Every deployment they did would provision a few VMs – one as a domain controller, one Windows desktop, and the rest for their internal products that needed testing. They used Jenkins (an open-source automation server) to execute their internal scripts inside this deployment. In this setup, the desktop became an agent for the Jenkins, also known as a Jenkins slave. The setup worked but was becoming slow and cumbersome.

 

When this company approached TeraSky, we decided to upgrade to vRA 8 and NSX-T. One of the major advantages of vRA 8 is the ability to take an existing environment and add it as a catalog item to the vRA. Many of our client’s customers wanted to save their deployments. With vRA 8, our client could take the requested deployment, create a deployment from scratch with nothing on it, allow the user to make any desired changes, and then save the deployment template to a new blueprint. This way, future clients would be able to request that same blueprint with the same changes directly from the vRA portal.

 

By taking a clone from the user deployment for the VMs with the changes that users have already made, cloning them to the side, and dynamically creating a specific blueprint for each user request, our client was able to build their “library” of blueprints. These “Save to catalog blueprints” takes around 30 minutes to deploy, as opposed to several days to prepare them manually each time. When a customer wants to test a specific feature for their product, this can save an enormous amount of time, especially when dealing with hundreds per day.

 

Another advantage of vRA is the concept of lease time. When a deployment is provisioned, it has a specific lease time. In the case of our client’s DevOps team, for example, the lease time for each deployment was three days. After three days, unless the user extends the lease further, the machine is powered off and then destroyed once the archive period expires. This solves a significant IT problem: waste and orphaned resources. When people leave their jobs or simply forget about deployments or automation, resources get abandoned and unnecessarily take up space and compute. Especially in the public cloud, where customers pay based on the resources that exist – whether they are powered on or not – this can be an expensive problem. vRA mitigates it with the lease time approach, ensuring that deployments that are not needed are quickly eliminated.

 

The next phase of the project involved implementing the same deployments and automation on the public cloud. In order to implement the solution in the cloud, we had to use TerraForm integration through the VRA. We wrote the Terraform configuration files for the provider and the back end, configured the GitHub, GitHub tab, etc. – anything that integrates with vRA. vRA then connects to the Git, sees the Terraform files we have uploaded to the Git, and then automatically integrates the files and builds a blueprint according to the Terraform file inputs. This enables the best of both worlds: TerraForm offers the infrastructure as a code capabilities with state file and tracks all changes, while vRA acts as an additional layer, providing the retention, the lease policy, the approval policy, and the resource management so all the customers will have a UI with same governance and the security policies and approval policies.

 

The complexity of both the client’s original setup and their requirements made the preparation for this project particularly critical. As always, we spent most of our time working with the client to fully understand the user needs, goals, and potential for scale. We dove deep into the existing environment with all of its features, learning what was working and what wasn’t, and what they really needed to achieve in order for the result to be suitable now and into the future. Only then did we move on to detailing the exact technologies and configurations we would be using, followed by the implementation of the automation. The result is a setup that saves our client and their users time and money, which means everyone can achieve their goals more efficiently.

 

Written by: Sagi Ilan, Hybrid Cloud & Automation Senior Consultant

If you still have questions, or would like to learn more about vRA 8, reach out to us! Our vRA experts are here to help.

Tags:
VMware
vRA
Terraform
vRA 8
Share:

Next Articles

Blog
      

21 April, 2024

Introducing TeraSky’s GKE PD Label Controller
Read Entry
Blog
      

21 April, 2024

Cybersecurity for DevSecOps: TeraSky’s Proactive Protection
Read Entry
Blog
      

27 March, 2024

AWS Generative AI Challenge!
Read Entry
Skip to content