One of the things I had always found difficult in translating to upper levels of management was the level of effort required to get vRealize Automation up and running in an environment. It was always a tough sell to add additional developers to staff to work on what is technically a COTS product, and being able to quantify that level of effort in a way that is also meaningful to the upper echelons of management (and not just us technically oriented folks) can be difficult. To be fair, this challenge is certainly not unique to vRealize Automation, but is common with all of the CMP platforms that I have encountered, as well as many other enterprise grade applications. That being said, going back several years now, I have toyed with the idea of counting the number of lines of code (or even the total number of characters of code) used in vRealize Orchestrator workflows and actions in an attempt to somehow quantify the level of effort required to stand up, support, and maintain the solution. However, it always seemed that as soon as I started to investigate ways to gather the required information that I would get pulled in five different directions and was never able to make much headway.
Continue reading “Counting Custom Code in vRealize Orchestrator”
Are you new to blogging, and do you want step-by-step guidance on how to publish and grow your blog? Learn more about our new Blogging for Beginners course and get 50% off through December 10th.
WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.
OK, so maybe the title of this post is a little over the top. The objective of this post is to help customers currently running vRealize Automation 7 and are looking at eventually migrating to vRA 8 to identify the system components that they are familiar with today in vRA 7 and how they map to vRA 8 components. This post will not cover elements that do not yet exist in vRA 8/vRA Cloud, but focus on what is available today. A lot of these elements do not serve exactly the same purpose in vRA 8 as they did in vRA 7, so I am focusing on the capabilities that each of them addressed; for example, in vRA 7, reservation policies allowed you to direct resources to specific reservations, which in turn eventually allowed the resources to end up on a compute resource tied to the reservation. In vRA 8, the equivalent would be using capability tags on your Cloud Zones and constraint tags in your blueprints to drive placement logic in your environment. This is certainly not an exhaustive list of mappings either, I’m certain that there are things that I have missed, but hopefully this will be helpful to those who are brand new to the vRA 8 platform.
Continue reading “vRealize Automation 8 Components Demystified”
This is the second post in a multi-part series covering the SovLabs IPAM modules from a solutions design point of view. In this post, we will be integrating the SovLabs Property Toolkit in with our IPAM module and the SovLabs Template Engine. By leveraging these solutions, our customers are able to dynamically apply IPAM configurations at the time of resource provisioning using a data-driven approach. These more advanced use cases will utilize metadata (think custom properties in vRealize Automation) directly from the request for a resource and use the metadata to dynamically select the IPAM configuration applied to the resource. All of the use cases we will cover have been seen during proof of concept engagements with real-world customers.
Continue reading “IPAM Design Deep-Dive – Part 2 – Property Toolkit Advanced Configurations”
This is the first post in a multi-part series covering the SovLabs IPAM Modules. In this post we will take a deep dive into some of the more common use cases we encounter with our customers as well as how we use the SovLabs Template Engine to dynamically set the correct IPAM profile on our blueprint. These posts are constructed from more of a solutions design point of view, rather than to be a step-by-step tutorial for setting up IPAM configurations (we have lots of those already at our blog page and on our support portal); what I hope to be able to communicate through these posts is how you can best design your solution to fit your specific use case.
I am starting with these less complex use cases because they will help to build some necessary foundational understanding which we will build on as we move to more advanced use cases in subsequent posts.
Continue reading “IPAM Design Deep-Dive – Part 1 – Standard IPAM Profiles”
One of the more common use cases that we help customers address during an engagement is translating their business logic for virtual machine placement into dynamic resource placement decisioning. The two main mechanisms that we use to achieve the desired result have existed in vRealize Automation for years; however, until just recently, if you needed to achieve automated results, you would have needed to write custom code in vRealize Orchestrator to address some of the advanced placement decisioning we have seen requested by our customers. Over the last few releases of the SovLabs Plugin, we have been steadily adding support for a number of special vRA Custom Properties that can only be addressed at runtime (aka runtime properties) and cannot be modified after a Catalog Item has been requested. In this blog post, I address two of these properties that help with resource placement decisioning: Vrm.DataCenter.Location and ReservationPolicyID.
Continue reading “vRealize Automation Dynamic Resource Placement with the SovLabs Property Toolkit”
Option 2: The SovLabs Property Toolkit Approach to T-Shirt Sizing
The second option to overcome this scenario would be to use the SovLabs Property Toolkit to enable t-shirt sizing in your environment. The SovLabs Property Toolkit allows you to dynamically apply an entire property group of configurations and customizations based off of a single selection in a request. The Custom Forms option shown in the first post in this series certainly works to overcome the Component Profiles limitations, but the SovLabs Property Toolkit is far more flexible in how to approach t-shirt sizing with vRA. A couple of the features to note that are possible when using the Property Toolkit for t-shirt sizing:
Continue reading “vRealize Automation – Remove Component Profile T-Shirt Sizing Constraints – 2 of 2”
- There are no constraints placed on machines provisioned from the blueprint.
- In the property group that is applied for sizing with the property toolkit you can use the SovLabs Template Engine to apply logic to your configurations. For example, a small Apache server will likely require less resources than a small SQL server. With the Property Toolkit you can offer up both applications in the same blueprint and apply the appropriate size as is applicable to each application.
- You can specify not only the number of cores to include for CPU sizing, but also the cores per socket and socket count to appropriately size VMs that extend beyond NUMA boundaries.
- Works with both Custom Forms and with traditional Blueprints.
- Zero Custom Code is required.
In vRA 7, Component Profiles give you a really simple way to address t-shirt sizing in vRA. One of the major drawbacks to using Component Profiles for t-shirt sizing, however, is that your machine becomes constrained for the lifetime of the machine by the bounds of the component profiles set on the blueprint when the machine was provisioned. For example, If I have three component profiles that have been added as Value Sets in my blueprint:
Small – 1CPU/2GB RAM/150GB Storage
Medium – 2CPU/4GB RAM/300GB Storage
Large – 4CPU/8GB RAM/500GB Storage
The machine that is provisioned from this blueprint will be constrained by the minimum and maximum values allowed. So, for the lifetime of this VM, when executing a reconfigure action, you will only be able to select a number of CPUs from 1-4, RAM from 2-8 GB, and Storage may not exceed 500GB. In this post (as well as the next) I’ll discuss a couple of solutions to overcome this limitation but still be able to offer t-shirt sizing in vRA.
Continue reading “vRealize Automation – Remove Component Profile T-Shirt Sizing Constraints – 1 of 2”
Limited XaaS Functionality in vRA 8.0
I want to start off by mentioning that VMware is listing Anything as a Service (XaaS) as being “built in” to vRA 8.0. The current implementation of XaaS in vRA8 is only a subset of the functionality that is available in vRA7. In the second part of this series (post 1 is available here) I am going to point out the major differences in XaaS functionality between vRA7 and vRA8.
SIGN UP FOR THE VRA8 BLOG SERIES & WEBINAR
Continue reading “vRealize Automation 8 – Identifying Important Gaps in Features, Functionalities, and Integrations (Part 2 of 2)”
Article by Sid Smith
In Part 1 of this two-part series on the vRealize Automation Migration Assessment Tool, we looked at the vRA8 migration tool to see how it might help you plan your migration from vRA7 to vRA8. In this article, we are going to look at what it will take to migrate your custom workflows from vRA7 to vRA8. To start, we will explore what a custom workflow looks like to day in vRA7.
SIGN UP FOR THE VRA8 BLOG SERIES & WEBINAR
Continue reading “vRealize Automation 8 – A First Look at the vRA8 Migration Assessment Tool – Part 2 of 2”
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.
SIGN UP FOR THE VRA8 BLOG SERIES & WEBINAR
Continue reading “vRealize Automation 8 – Identifying Important Gaps in Features, Functionalities and Integrations – Part 1 of 2”