Introduction
As I began to draft this article I took some time to reflect on December of 2015. At the time I was involved with systems architecture for a large organization where we had rolled out vRA 6.2 in production for the first time about 5 months prior. vRealize Automation 7 had just been announced, and we were ready to start working with the new platform to put it through its paces. We installed vRA 7.0 within the next month or two and pretty early on in the process identified that the product was not capable of synchronizing our existing security groups with the solution because of the organization’s policy of having a special character included in the name of the majority of our security groups. We were very familiar with this issue because, when we first started working with an earlier version of vRA 6.2, we had run into the same issue. That issue had been remedied in a later version of 6.2, only to have the same issue resurface again in 7.0. It wasn’t until 7.2 that the special character issue was resolved, and then it took us another 8 months to restructure our blueprints, re-write custom code, and migrate the entire environment.
{{cta(’58c71586-bbe1-4867-bf96-b66ee58b4caf’,’justifycenter’)}}
I tell this story because I believe that it is imperative that you start working with vRA8 no later than version 8.1 in a development environment. With the vRA8 product being redesigned from the ground up, you will want to identify potential deficiencies early on so that they can be addressed in the product. The purpose of this article is to highlight some of the high level features, functionalities, and integrations that we have already encountered that are noticeably missing in vRA 8.0, so that you can focus your efforts on other areas that may be important to your organization.
Before getting started, I want to note that some of these gaps have already been acknowledged by VMware, and are (hopefully) being addressed in vRA 8.1 or 8.2. Our primary goal with this article is to be sure all of the major gaps we have identified in the product are already clearly defined, so that vRA users are well educated when making the decision whether or not the time is right for them to migrate to the new platform.
Approval Policies
If you are using approval policies today in vRA7, or if you require that requests are appropriately governed and are considering vRA8 for your enterprise deployment, you need to be aware that approval policies do not exist in vRA8. Many of the customers we work with rely on the approval policy constructs built in to past versions of vRA. Again, approval policies do not exist in vRA8.
Multi-Tenancy
In vRA 8.0, multi-tenancy is not available. VMware has hinted that multi-tenancy should be reintroduced in vRA 8.1. In vRA 8.0 you can even see that the constructs exist for something called organizations. Because it will still be a few months until anyone is able to see how VMware will approach the idea of multi-tenancy in vRA 8, there is still quite a bit of investigation required once multi-tenancy is released.
Property Dictionary
If you were leveraging the property dictionary, property groups, and property definitions in vRA7, you need to know that there is no property dictionary — or its equivalent — in vRA 8.0. In addition, custom properties are no longer available on most of the endpoints in vRA8 (think Endpoints, Compute Resources, etc.) for propagation down to provisioned resources (see this post for more detail).
Licensing Differences
VMware has added many new capabilities with the new platform. You should know that most of the big-hitter type capabilities — including AWS, Azure and Google Cloud deployments, Kubernetes support, and Code-Stream integration — all require a vRA8 Enterprise license. If your organization requires basic IaaS and XaaS type deployments to on-prem resources only, you will only need Advanced-level licensing. However, most of the newly added features that have been focused on in the marketing campaigns to date will require vRA Enterprise licensing. Here is the link to the official vRA page showing the difference in the two versions. I have included a screenshot here as well.
Configuration Management
Much of the marketing for vRA8 points to the fact that your configuration management tools will continue to be available directly from the blueprint design canvas. You can drag and drop configuration management blueprint components directly on to your canvas when designing a blueprint. As in vRA7 though, you should note that this feature is only available in the Enterprise version of vRA8, and that, depending on the CM tools that you are using the integrations, is quite a bit different than what was available in vRA7.
Ansible Integration
The first thing to note with the vRA8 Ansible integration is that vRA8 supports only Ansible Open Source, not Ansible Tower.
Opting to integrate Ansible in this fashion does not allow execution of day two operations from Ansible, role-based access control, the capability to schedule jobs, graphical inventory management, or external logging integrations. All of these functionalities are possible if you are using Ansible Tower.
Puppet
The Puppet integration will allow you to specify roles, hosts, and credentials, but it does not offer the ability to invoke the Puppet agent as many times as you’d like. The Puppet Integration also does not allow you to use alternative node classification, drive hiera, factor, specify alternative exit codes, or parse the logs for regular expressions that would signify a success without requiring an exit code. The native Puppet integration in vRA8 is rudimentary and perfunctory, but not at all robust or tolerant of real world conditions in which modules may not perform as expected 100% of the time.
Summary
There is a ton of added functionality included in vRA8. With the addition of Cloud Agnostic blueprints, support for Kubernetes, and Code-Stream capabilities built in, there is a lot to look forward to in this new offering. However, there are also several feature gaps in vRA 8.0.
Some organizations are ready to use the product today, while most organizations may be better off waiting until some of these feature gaps are mitigated. If any of the features as identified above fall into the requirements category for your organization, vRA 8.0 is likely not ready for production use in your organization. But, no matter what your requirements are, I would highly suggest starting to work with vRA8 today. Start investigating your use cases to identify where the product meets or falls short of your requirements.
Stay tuned to the SovLabs Cloud Automation Blog for Part 2 of this series, in which we will address additional gaps specifically within the available XaaS component.
