It’s no secret that eliminating complex manual processes reduces tech debt, decreases the likelihood of human error, and improves IT efficiency. However, when it comes to building private cloud solutions and integrating public and private cloud platforms the level of customization and complexity required often leads to IT using manual processes they’d prefer to avoid.
In VMware environments, vRealize Automation (vRA) infrastructure automation helps solve this problem. In this article, to help you get the most out of this automation tool, we’ll review the platform in-depth, explore what’s changed in vRA 8, and walk through the deployment process so you can get hands-on with vRA.
vRealize Automation: A crash course
vRealize Automation, currently at version 8.6, is part of VMware’s vRealize Suite. The vRealize Suite includes a variety of software solutions aimed at operations, automation, orchestration, and cloud.
vRealize Automation is primarily a private or hybrid-cloud utility. It can be used to provide customers with access to applications, services, and virtual machine (VM) deployments via a web portal.
vRA also provides mechanisms for extensibility and integration into and between third-party infrastructure and application management tools and public cloud platforms such as AWS and Azure.
The different vRA capabilities can be categorized as Infrastructure as a Service (IaaS), IT as a Service (ITaaS), and Anything as a Service (XaaS).
The specific capabilities of a given vRA instance depend on the vRealize license in use. The table below details the different capabilities for the two current vRealize license types.
vRealize Automation License Comparison | ||
---|---|---|
Capability | vRealize Advanced | vRealize Enterprise Edition |
IT Services | Infrastructure only | Infrastructure and applications |
Clouds | On-premises and VMware Cloud | Any cloud |
Resource lifecycle management | Included | Included |
Native public cloud services | Can embed native public cloud services constructs in blueprints | |
Integration with configuration management tools | Included | |
Kubernetes support | Included | |
Cloud agnostic blueprints | Included | |
VMware Code Stream | Included |
The history of vRealize Automation: From DynamicOps to vRealize Automation
vRealize Automation was originally an internal project at the famous investment bank Credit Suisse. The bank used the tool to automate Windows deployments. It proved so successful that they decided to go public with the software and formed an off-shoot organization, DynamicOps, via venture capital. It was marketed under the name Cloud Automation Center in 2008.
Cloud Automation Center was designed to automate the deployment of virtual machines against different hypervisors, including ESX, Hyper-V, and Xen, and the provisioning of physical systems via DRAC and iLO.
Because of this multi-platform capability, it used many different connective agents, leading to complex deployment and architecture, particularly in highly available (HA) configurations.
The main components of the Cloud Automation Center product were a Windows Server that acted as the IaaS Server and an external MS SQL Database. These servers enabled provisioning and managed the lifecycle of virtual machines via Windows Workflow Foundation (WF). An additional Windows server running IIS provided the Cloud Automation Center user interface.
The DynamicOps acquisition, creation of VCAC, and feature expansion
In 2012, VMware purchased DynamicOps, and the technology evolved to become vCloud Automation Center (VCAC). VMware added a new front-end web portal and began the long process of rewriting large swaths of code with each new upgrade.
After the rebranding, VMware added several new features to VCAC. For example, updates introduced a new mechanism to interact with “Endpoints” via Distributed Execution Manager (DEM). DEMs consisted of two types, Workers and Orchestrators. The Worker’s job was to execute IaaS lifecycle workflows (provisioning operations) while the Orchestrator kept track of the Worker’s status and the workflow’s execution state.
Typically, two Orchestrator machines were deployed onto Windows servers for High Availability, with one being active and the other passive. Multiple DEM Workers were deployed, with each one interacting with a specific target, such as AWS, Openstack, RHEV, or SCVMM.
VMware also added support for multi-tenancy, identity management, per-tenant web portal branding, approval workflows, and XaaS via integration with vCenter Orchestrator (vCO).
vCO, now known as vRealize Orchestrator, is an extensibility tool that can execute custom code against a target. It can utilize REST and SOAP or even SSH connections to connect to any server or application and execute scripts, commands or API calls as part of an automation workflow. It ships with several API plugins to connect to platforms like vCenter and NSX immediately out of the box. Additional plugins are available via third-party vendors and can even be created by individual developers as needed.
VCAC becomes vRealize Automation Center
In 2014, VCAC was rebranded vRealize Automation Center (vRA) and added to version 6.2 of the vRealize Suite.
At this point, vRA became extremely powerful. However, it was also very complex. The major components of vRA were usually installed onto separate servers and often doubled up and placed behind load balancers for high availability. At this point, components of vRealize Automation included:
- vRA Appliance: The modern web portal for end-users, providing a configurable catalog of services based on their identity.
- IaaS Website: The legacy DynamicOps web portal, still used but referenced and accessed via the vRA appliance portal.
- Model Manager: Contained the IaaS business logic to deploy machines via workflows against target systems.
- IaaS MS SQL Database: Used to store IaaS data.
- DEM Orchestrator: Took instructions from the Model Manager and executed them against an appropriate DEM Worker.
- DEM Workers: Performed provisioning operations against a target system such as AWS or Microsoft’s System Center Virtual Machine Manager and so on.
- Proxy Agents: Agents were used before the more intelligent DEMs. For legacy support, proxy agents were still required to interact with target endpoints such as vCenter, Hyper-V, VDI infrastructure, and WMI. An agent was required per endpoint, so if you wanted to provision VMs to two vCenter Servers, two agents were required. These agents were installed onto Windows servers.
- vRealize Orchestrator: An orchestration and workflow development engine deployed in pairs for high availability.
- vRealize Business: Provided resource analysis, costing, and chargeback utility.
- NSX: An optional component used to provide network objects for virtual machines.
Troubleshooting, deployment, and general manageability became significantly complex given the complex stack of components. For example, the diagram below demonstrates how a robust enterprise-grade deployment may have been configured.
Reducing complexity with vRA 8 Architecture
VMware recognized that vRA’s complexity needed to be addressed, and they did just that with vRA 8.
In many ways, vRA 8 is a different product operating under the same name. Legacy code is gone and the architecture and APIs have undergone a complete overhaul. For example, there are no more Windows Operating system dependencies, freeing up license costs and avoiding vendor lock-in. Additionally, the new architecture is streamlined and consists of far fewer components.
vRA 8 is containerized
To provide high availability while maintaining simplicity, VMware containerized the various vRealize Automation services. Docker is used to physically run the services as containers via Helm, while a special self-deployed and self-managed distribution of Kubernetes orchestrates and provides service availability and accessibility.
vRA is now just three appliances!
At its most basic, a vRA deployment now consists of the following appliance types:
- vRealize Suite Lifecycle Manager Appliance: Handles the installation, patching, upgrading, and configuration management of products within the vRealize suite.
- VMware Identity Manager: An Identity as a service (IDaaS) solution used by vRA as an SSO mechanism, allowing login and authentication to vRA.
- vRealize Automation: A Photon Linux appliance running the core functionality, user interface, and business logic.
“The CloudBolt team has been with us on this journey to self-service… This level of partnership and shared direction has enabled Home Depot to move faster, move further and continuously enhance our offerings to our Development Team customers.”
– Kevin Priest, The Home Depot
New vRealize Automation Terminology
vRA 8 also comes with a new set of terms and concepts. For example, vRA 7 Reservations and Reservation Policies have been by Capability and Constraint Tags in vRA 8. Below is a mapping of old versus new terminology for popular vRA objects.
vRealize Automation Terminology vRA 7 vs. vRA 8 | |
---|---|
vRA7 | vRA8 |
Blueprints | Blueprints |
XaaS Blueprints | Service Broker Content (ABX/vRO) |
Software Components | Cloud-Init (Linux), Cloudbase-Init (Win) |
Business Group | Project |
Reservations | Capability/ Constraint Tags |
Endpoints | Cloud Zones |
Cluster Compute Resource | Compute |
Naming Prefix | Custom Naming Template |
Reservation Policy | Capability/ Constraint Tags |
Storage Reservation Policy | Storage Profile |
Entitlement | Content Sharing / Day 2 Actions Policy |
Network Profile | Network Profile |
Template | Image Mapping |
Component Profile | Flavor Mapping |
vRA 8 new capabilities
Along with a streamlined architecture, vRealize Automation now ships with several new capabilities, including:
- Multi-cloud support: Ability to deploy Hybrid Cloud into Azure, Google Cloud Platform, and AWS.
- Native Cloud Features: vRA can embed third-party cloud constructs and objects into vRA Blueprints.
- Cloud Agnostic: Blueprints can be designed to deploy into any cloud without requiring custom configurations or specifications.
- Infrastructure as Code: Blueprints are implemented as YAML via a drop and drag design canvas.
- Action Based Extensibility (ABX): Enables extensibility via Python or Node.js as an alternative to vRealize Orchestrator workflows.
- vRO Integration: vRO now runs as a Kubernetes managed service directly inside the vRA appliance.
- Kubernetes workload support: vRA can manage Kubernetes-based workloads.
- CodeStream: Helps to automate the release process for software, including development and testing phases.
vRealize Automation Deployment Options
There are two vRealize Automation deployment options:
- Standard: For testing, proof-of-concept, and smaller environments
- Clustered: For larger, highly available, enterprise-grade environments
The Standard Deployment Architecture uses three appliances as demonstrated in the diagram below.
With Clustered Deployment Architecture vRA runs across three clustered appliances behind a supported load balancer (such as NSX-T). VMware Identity Manager is also clustered across three appliances and accessed via a Load Balancer. The load balancer is configured to regularly test the health of the appliances and redirect traffic to surviving members should one fail. The vRealize Lifecycle Manager is placed into an HA-enabled vSphere cluster but is deployed as a single node and does not yet support being clustered.
vRealize Automation 8 Deployment Process
The vRealize Easy Installer streamlines vRA installation and makes deployment far less error-prone than previous versions of vRealize Automation. The basic vRealize Automation installation steps are:
- Download the vRA Easy Installer ISO from VMware
- Mount the ISO and run the installer
- Deploy vRealize Lifecycle Manager via the installer
- VIM is deployed by Lifecycle Manager
- vRA is deployed by Lifecycle Manager
- vRA is configured and the vRA services are started
vRA 8 pros, cons, and missing features
While vRealize Automation 8 offers many improvements over the older versions of vRA, no platform is perfect. There are both pros and cons when an enterprise transitions from vRealize Automation 7 to vRealize Automation 8.
Pros of vRA 8 include a wealth of new features, support for a wider range of public clouds, and streamlined deployment and maintenance workflows. However, for organizations with existing vRA 7 deployments, the fact vRA 8 is so architecturally different and the API is not backward compatible can be a major con. These teams will have to perform significant rework to make vRealize Automation 8 operate like their existing platform.
For a deeper dive on the complexities of migrating to vRA 8, see The Truth About First Generation Cloud Management Platforms: A Focus on VMware vRealize Automation. As this survey shows, one of the main challenges in upgrading from vRA 7 to vRA 8 is the time investment required to migrate all of the custom code and integrations.
The other major challenge of migrating to vRealize Automation 8 is the long list of missing features. Many features from vRA 7 simply aren’t in vRA 8, and while some may eventually be added, others may not. Instead, VMware may aim for “use-case parity” where vRA 8 solves the same problems using different mechanisms.
Below is a list of “missing features” in vRA 8 and the alternative methods administrators can use to achieve comparable functionality.
vRealize Automation 8: Missing Features | ||
---|---|---|
Missing Feature (was in vRA 7) | Function | Alternative |
Approval Workflows | To provide a control and approval mechanism for deploying machines and services. | vRA can halt the workflow, pass the approval to ServiceNow, and continue once approval is provided. |
Multi-Tenancy | Allows different clients to log in and see different services. Tennants cannot access resources belonging to other tenants. | Multi-tenancy is possible but within a “Project”. It is not currently possible to provide two users with different catalog views. |
Property Dictionary | Used to provide custom values to object configuration, such as disk size or RAM | Key-value pairs via Tags |
Ansible Tower | Automated application configuration and deployment | Ansible Open Source is supported |
Endpoints | Targets that vRA can connect and deploy workloads to | Many endpoints can be added as cloud accounts or integration accounts. Select platforms are no longer supported at all. See this VMware article for details. |
Resource Quotas | Provide a limit to the resources that a tenant can provision | Reservations have been removed, but Cloud Zones provide limits. |
Custom Actions | Day Two operations on objects. E.g. an option against a VM to add another disk. | Use a vRO workflow |
Conclusion
vRA 8 is a capable, popular, and flexible cloud platform from a trusted, enterprise-grade vendor with excellent support. It is not an exaggeration to say that vRealize Automation can be configured to do almost anything. That said, upgrading from previous versions to 8 can be significantly complex. However, with vRA 7.6 support ending in 2022, organizations using older versions will need to act fast if they haven’t already migrated.
Related Blogs
The New FinOps Paradigm: Maximizing Cloud ROI
Featuring guest presenter Tracy Woo, Principal Analyst at Forrester Research In a world where 98% of enterprises are embracing FinOps,…
Navigating the Human Side of Automation: Culture and Change Management [Walk Phase – Part 2 of 3]
In our previous post, we explored how to lay the groundwork for automation by focusing on the essential processes and…