On Tuesday, December 10, we delivered two sessions of a webinar focusing on the “Top vRA8 Deployment Considerations”. Here is the recap of the webinar and all our supporting content, including the full recording of the first session. Each session ended with about 20 minutes of Q&A from the audience. Below, are all the questions and answers from both webinar sessions.
Q: Is the SovLabs policy management using a new platform outside vRA?
A: The PM we currently have in vra7 today is built as part of vra7. It is a vro plugin for our product set that uses these policies. The policies are going to be able to be migrated to our next gen platform, which is a new platform outside of vra. So it’s going to be our own appliance that runs in the environment. There will be a lightweight plugin within vra7 or vra8, that will talk to our centralized appliance that runs our platform that has your policies configured. This platform is being built “API first”, so even if you’re using other tools that you want to consume intergrations from, you can do so using the REST API. And we’re also working on end point integrations for other things like Terraform and other products.
Q: What is the SovLabs next gen platform?
A: We’re taking our integrations, and putting them into our own appliance so they can be consumed centrally from whatever it is you want to consume them from, like vRA7, vRAC, vRA8, etc. These integrations and end points can be consumed via the API or other end points that we will release. This new platform will give you a method of managing your end point integrations from every different platform you want to consume them from.
Q: When do you believe vRA8.x will become a viable platform along the lines of what we can do with vRA7 today?
A: Great and very difficult question to answer. VMware says there will be significant changes in vRA versions 8.1 and 8.2. The promise is that v8.2 should bring parity for most things in the 2nd half of 2020, but it’s really hard to say when that will be.
Q: Will the SovLabs next gen platform be on premise or cloud/SaaS?
A: Our appliance will be on premises. We’re investigating potential cloud implementation, but when it comes to integrating and tying into disparate systems, most organizations do not want that data in the cloud today.
Q: When will the SovLabs next gen platform be available and when will it support vRAx and/or VRA cloud?
A: Our target is around the same time frame as vRA8.2, sometime in the second half of 2020, though that could change.
Q: Will the SovLabs next gen platform also fully support VMC on AWS?
A: We have support for VMC on AWS today. There is one of our integrations that’s not certified, and that’s because they (AWS) limited some of the APIs that are available for VMC (tagging). Just like running vRA on prem, you’ll be able to use the plugin and communicate with the platform using VMC on AWS. It’s just a matter of whether any of our individual modules that may not have the APIs. The limitation is vsphere DRS. Some of the APIs in vsphere are not exactly on par for private cloud. So, vsphere DRS is the only thing that is impacted from SovLabs on the integration side.
Q: I’ve been told based on what my company uses today within vRA7 could require an enterprise license to get features like agnostic blueprint and cloud provider. Do you have any suggestions?
A: This is a struggle with vRA7 today too. A lot of folks have enterprise licenses to be able to execute or use software components to execute scripts and things like that. All except one of our modules today do not require an enterprise license. We have a version of Ansible Tower that works with Enterprise for doing the drag and drop capabilities on the canvas, but we also have Ansible Tower integration that does not require the use of vRA enterprise. That’s going to hold true with our next gen as well. It really depends on how the integration is going to be consumed, but our goal is to try to build our modules and integrations so they do not require those types of upgrades to higher versions.
Q: Will the SovLabs next gen platform support any other platforms other than vRA?
A: Yes. We are looking at Ansible Tower integration and possibly a Terraform provider for our next gen platform. We will offer a number of different ways to consume these integrations from other platforms other than vRA, as well as the ability to consume such integrations via the REST API. As an example, there may be a configuration in vRA7 that’s done via the custom property constructs that exist in there today, where we have property groups where we can through our property toolkit, we can make use of property groups in a much more expanded way than what vRA7 allows. For example, being able to take a singular input as part of a request in vRA and translate that through to a property group so that one input can have a greater impact on the request. That one property can become many.
Q: Will the SovLabs next gen platform have some high availability architecture or will it be just a single appliance?
A: We are building it with high availability in mind, to the same standards that one would expect in an enterprise grade data center. All of our modules are engineered to be enterprise grade. Our next gen platform will take things like naming to the next level, like being able to validate against internal or external DNS, other vRA environments, etc., giving you the ability to do the appropriate validations.
Q: How do I know based on my use case when we should consider moving to vRA8?
A: Many of our customers are struggling with this decision. If you are a net new vRA8 customer (meaning you’ve never implemented vRA7), and you’ve validated that vRA8 can meet the requirements of your use cases today, there is no reason not to deploy vRA8 today. However, most organizations that are already utilizing vRA7 today, and have elaborate, mature, complex vRA7 deployments, it’s going to be some time before vRA8 becomes a reality in your environment. That doesn’t mean that you shouldn’t start deploying, learning, and becoming familiar with vRA8 today, but for it to be ready to support most mature vRA7 deployments, we’re probably at least 12-18 months away. Today, vRA8 is lacking some of the needed features, and, with the transition to vRA8 for any custom integrations, it’s going to take some time.
Where SovLabs can help today is working to help customers get transitioned off of those custom workflows today onto off-the-shelf out-of-the-box integrations, so that those customizations become a non-issue for the migration from vRA7 to vRA8.
Q: Can you share reasons for why we should separate out extensibility from being tied to our CMP?
A: For a decentralized model, where you’re managing integrations in each separate environment inside of your CMP or your other tools like ServiceNOW, if you’re managing those integrations independently, you run the risk of overlap, in which these integrations start competing with one another, which can very easily happen in an automation environment.
Q: We use vRA for lifecycle management with ServiceNOW as the request portal. Do you have a solution to integrate vRA7 with ServiceNOW?
A: Yes, we have two ServiceNOW integrations. We have a Service Portal integration for ServiceNow that allows you to consume and use vRA blueprints from within the ServiceNOW catalog to use ServiceNOW as your primary catalog. We also have a CMDB Module that allows for CI records to be created within ServiceNOW. The two modules work hand in hand to provide some Day 2 Operations within ServiceNOW, so you can provide your users with the ability to make those requests and manage those machines from a Day 2 perspective as well.
Q: Will your new platform support multiple personas?
A: Yes, for Administrator and Provider/Consumer. We’re also identifying as a new persona the end point subject matter expert will be able to manage the integrations themselves. One of the challenges we’ve seen quite often is the IPAM or F5 admin or Ansible Admin is not necessarily the Cloud Admin in charge of vRA, so it’s difficult to get the SME to come to a CMP to build the integrations. It’s usually the other way round: the cloud management expert is trying to figure out the end point tools and technology and build that inside the CMP. With SovLabs next gen we will service those SMEs. If they want to self-administer and manage and create their own services, they can do that. Those services can be consumed anywhere via API through the policies. The same policy which is the configuration for how you execute in vRA7 is going to be part of next gen, but it does not have to be limited to the cloud admin that can configure, monitor, and manage those integrations. That can be the SME as well.
Q: What about the vRA Guest Agent?
A: With our modules today, we have support for doing deployments and executing scripts within vRA7 that do not require the vRA Guest Agent. It is not clear whether the Guest Agent will exist in vRA8, but even if it does, we find that a lot of organizations do not like to use it or be dependent on it. We offer the Lifecycle Components Toolkit, which allows you to invoke and execute scripts within those guests without using the Guest Agent. We can do things like slip into the VMware tools or SSH to 1RM to interact with the Guest LS so no agent is required, nor would you be required to have an enterprise license to execute those scripts within guest machines.
Q: Are these new methods available in vRA7.6 or specific to vRA8?
A: Our new platform is specific to SovLabs next gen. Profiles exist in 7.5 and 7.6, but our next gen platform will support both vRA7 and vRA8.
Q: Can we export/import deployment endpoints from vRA7 to vRA8?
A: Yes, the idea is to be able to migrate them over to the next gen platform.
Q: Will our next gen solution support platforms other than vRA?
A: Yes. The REST API will support doing things through ServiceNOW. For example, many of our customers would like to generate a name for a physical asset that they are deploying as part of that deployment. Whether it’s a router, switch, or physical server, you will be able to provide those as catalog services in things like ServiceNOW. We have Terraform, Ansible, and we are working on integrations so you can consume these integrations through whatever platform you wish to consume them from.
Q: If you don’t currently have a module for a particular endpoint vendor, is SovLabs going to create a new one, for example for Netscaler?
A: Yes, we have 30+ modules today, and we’re constantly working with our customers to determine what new products we can support for integrations. If you’re looking for a new integration that we do not currently offer, the more we know the more we can build, so please contact our support department to discuss what integrations you need that we don’t currently offer.
Q: Will liquid code be used to provide dynamic custom properties in vRA8?
A: We will maintain vRA7 template engine in our next gen platform. However, from our understanding, vRA8 will not use liquid code. vRA8 has its own templating language.
Q: Does your centralized management support multiple environments?
A: Yes. That’s what we do today in vRA7. You can create naming standards that are highly dynamic based on different environments or you can create policies per environment and consume them according to your use case. The same thing will apply with the SovLabs next gen platform as well. You can have a single policy that’s driven more dynamically using template engine logic to make determinations or you can use different policies for those different environments.
Q: Is SovLabs next gen anticipated as an OVA style appliance install or only as a SaaS offering or both?
A: It’s going to be an on-prem OVA. We are building it as a container-based appliance so that if we determine that there is enough demand to make it a SaaS solution we will do that as well. From our research to this point, looking at this type of solution that would be able to talk to a large amount of the IP infrastructure in your environment from an integration perspective, most enterprises are still skeptical about putting that out on a SaaS environment today.
Q: Will the SovLabs next gen support tenancy?
A: Yes. We will be supporting multi-tenancy and high availability, so SovLabs will be inline with what one would reasonably expect from an enterprise environment. We get our HA today by being part of vRO, and we want to maintain that same level of service when we migrate to our own appliance.
Schedule Your Custom Demo
Thank you to everyone who registered, attended, and participated in this webinar on our early findings from within vRA8. To schedule a free custom demo with Sid or one of our other vRA experts, please contact us here.