A VMware Admin’s First Impressions of vRealize Automation 8 (vRA8) – Part 1 of 2

Many of us have been eager to get our hands on vRealize Automation 8 (vRA8) for some time now. If any of you are like me, you may have dabbled in the Hands On Labs with vRealize Automation Cloud (formerly CAS) for the past year. But, without having the capability or the requisite login for the service, you kept abreast of any updates coming out of the vRAC camp. I have been through quite a few versions, upgrades, migrations and code changes in my time working with the vRealize products. Most of this experience was spent in architecture, engineering, and development at a large enterprise customer, where we had to carefully navigate each of these changes. This article covers some of my first impressions of vRA8 as an advanced user of the product since the early days, circa vRA6.

Introduction

There is a lot to cover here. The product has been re-written from the ground up. The Cafe and IaaS nodes that we are all familiar with are now gone. Custom workflows will most likely have to be completely re-written. Migrations will have to be planned and extensive testing required prior to any production deployment. It will likely take the better part of the next year for the community to get a handle on the new product. However, if you’re reading this blog post, you are probably actively engaged in working with vRA in some fashion, and you’re excited to see the new capabilities offered in vRA8.x.

The following is a two-part summary of some of the very high level aspects of the new system that have jumped out at me in the first 2-3 weeks of working with VMware’s reconstructed code for vRealize Automation. In part one, I explain my experience working with the Documentation of vRA8 and Tagging, the new way to manage your machine metadata.  Part 2 will cover my take on ABX and Policies. Also, we’re going in depth on these and other topics in our December 10th webinar: Top vRA8 Deployment Considerations. Click here to sign up.

Documentation and Community Backing

Learning a new platform and a new application architecture always come with challenges, and often times those challenges relate to how well the product is documented. That being said, to get off the ground with vRA8, I was able to fairly easily follow the process of preparing my infrastructure for resource deployment. I completed that portion of the setup in about 30 minutes (not including the initial deployment) and, for the most part, clearly understood what was going on with the new components (Cloud Zones, Flavor Mappings, Image Mappings, etc.). Where I started to hit some difficulties was in going through building my first blueprint and making it work with other constructs in the environment. YAML is a new concept for me, and, while I found that the editor was intuitive, when I wanted to do something outside of a basic VM deployment, the documentation didn’t have very many advanced use case examples.

The documentation is available right from the portal, which makes having to reference something much easier than in past versions. And, you can select the link to take you right to the VMware docs page. Just be careful, because that link will display search results for all VMware products, although these results can be further filtered to include just vRA8.

It doesn’t appear that all of the search results are available in the portal either. My results for “blueprint” above (5 results) showed 163 results on the official documentation site.

Introducing the vRA8 YAML Editor

When creating blueprints in past versions of vRealize Automation, the vRA Custom Properties Reference was an invaluable resource in showcasing the available properties for use in a blueprint. Sure, there are some “hidden” properties that never made it into the reference, but the community often filled in those gaps. In vRA8, there are multiple types of blueprint components, each translates to a different platform, and each of them has different available properties. One of the things that vRA8 executes well on so far is the ability to view the available properties for a given type directly from the YAML editor in the blueprint designer.

However, what would be immensely helpful is a reference document of available properties as they pertain to each component type, as well as what each of these properties does, and their expected inputs. These properties should be documented somewhere for reference away from the blueprint design canvas.

Brand New Code: Brand New Community Resources

In addition to the vendor-provided documentation, I would argue that almost as important as the official product documentation are the available community resources for a product. The community backing and backlog of available resources for vRA7 is astounding. That being said, unfortunately very little (if any) of what was written supporting vRA7 applies to vRA8 because of the new architecture. There are not very many resources available on the internet today for helping with a new vRA8 deployment, configuration, and development. What is available often applies to vRealize Automation Cloud (aka vRAC, which is slightly more mature due to its accelerated release cadence) and may or may not apply to the on-prem vRA8 product yet. In another 6 months, when the vRAC features are rolled into the next release of vRA8, those articles will become much more valuable. Until the community has had a chance to build a substantial amount of content surrounding the new platform, this deficit of support content and materials should absolutely be taken into consideration when determining whether or not to deploy the new platform in a production environment.

Tagging, Custom Properties, and Propagation

With vRA8 comes a new way to manage your machine metadata. In the new platform, there are tags, capability tags, constraint tags, standard tags, project tags, project constraint tags, and custom properties. There is a bit of tag overload going on here. Some of these tags are used in placement decisioning, some of them propagate from higher level objects and go on to set tags on the endpoint itself, and some of them do not. According to the VMware documentation, each of the referenced tag types are defined as follows:

• Capability Tags: enable you to define placement logic for deployment of infrastructure components
• Constraint tags: You add constraint tags to blueprints and various other components within vRealize Automation Cloud Assembly to match capabilities defined on resources, cloud zones, and profiles to generate appropriate deployments.
• Standard tags: vRealize Automation Cloud Assembly applies standard tags to some deployments to support analysis, monitoring, and grouping of deployed resources. Note: although these are documented, I cannot seem to find them whether in the GUI or the API. I’m not sure of the overall intent behind them, or where they may actually be able to be referenced since they are not readily accessible in either the API or the GUI.
• Project Resource Tags: A project resource tag operates as a standardized identifying tag that you can use to manage the deployed resources and ensure compliance.
• Project Constraint Tags: A project constraint operates as a governance definition. It is a key:value tag that defines what resources the deployment request consumes or avoids in the project cloud zones.

A Change to Custom Properties

In vRA8, custom properties are not like they were in vRA7. Custom properties can still be applied to a resource to specify metadata about that resource, but they are noticeably missing from infrastructure endpoints, and appear to be limited in total functionality.

From what I can tell, the only tags/custom properties/metadata that propagates down to deployed resources — such as virtual machines — are project resource tags and tags set on the resource itself in the blueprint. I see this change as a major shortcoming in the product. We have worked with hundreds of customers who have realized simplified provisioning by being able to set Custom Properties directly where they were most applicable. Without the capability to specify metadata on the endpoints (cluster, vCenter, storage, network, etc.) and to have that metadata propagated during deployment, it can potentially lead to increased blueprint complexity, blueprint sprawl, and an increase in technical debt.

Thanks for reading Part 1 of this two part post. Stay tuned for part two — ABX and Policies — and go ahead and register for our December 10th webinar: Top vRA8 Deployment Considerations. Click here to sign up.