Posted on

vRealize Automation 8 – A first look at vRA8 Migration Assessment Tool: Part 2 of 2

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

vRA7 Workflow Components

In vRA7, there are a number of components that come together to make the magic happen.  Each component plays a vital role in how you design, build, and invoke your customizations.

Event Broker

The event broker was introduced in vRA7 to make it easier to trigger the workflow stubs that existed within the IaaS server.  These stubs were always there, but only a handful were accessible and they were not easy to configure. The Event Broker also introduced a more granular way to decide when a workflow should or should not be executed.  Although the event broker has dozens of events you could subscribe to the following were the most commonly used:

  • Machine Requested
  • Building Machine
  • Machine Provisioned
  • Machine Activated
  • Machine Destroyed

Many of these states included a pre and a post execution allowing you to decide if you wanted to execute your workflow before of after vRA’s execution of that state.  These states that are the core of vRA7 extensibility no longer exist in vRA8. vRA8 is a completely new platform, written from the ground up, and no longer includes the IaaS host that controlled all of these states in vRA7.

Read the full article here

Posted on

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

Article by Mike Bombard

Welcome to Part 2 of 2 of our “First Impressions” of vRA8 article. In Part 1, we discussed what’s new, good, not so good, and really good about Documentation and Tagging in vRA8. Below, we discuss ABX and policies, which are both very new and very different in vRA8.

Action Based Extensibility (ABX), vRealize Orchestrator and Extensibility

ABX is the new extensibility offering packaged with vRA8 (in addition to vRealize Orchestrator) that uses a FaaS provider (AWS, Azure and On Prem offered today) to provide extensibility for the new platform. As someone who has spent countless hours working with vRO, ABX is probably one of the more intriguing announcements surrounding vRA8. 

One of the things that I am impressed with right out of the gate is that the ABX action runs show you the code that was used as well as the payload that was passed for use in the action. In fact, both Orchestrator and ABX runs can be monitored directly from the Cloud Assembly UI. No more having to log in to a separate interface to see what is happening with your extensibility. This methodology makes troubleshooting much more accessible.

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

Read the full article here

Posted on

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

Article by Mike Bombard

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.

Read the full article here

Posted on

vRealize Automation 8 – A First Look at the vRA8 Migration Assessment Tool — Part 1 of 2

vRealize Automation veterans may still remember the migrations from vRA 5.x to 6.x and 6.x to 7.x. However, for many enterprises utilizing vRealize Automation, the migration from vRA 7.x to vRA 8.x will be your first major vRA migration. In an ideal world these migrations would only take a few clicks of the mouse.  Migrating from vRA7.x to vRA8.x is going to be a lot like switching banks. Trying to figure out all the services that have your bank card on file for automatic billing and moving over automatic bill payments is tedious and time consuming. Which payments are monthly, quarterly, annually, and for how much? Wouldn’t it be nice if there were a simple tool to identify and update all the services that you have on auto-pay?

SIGN UP FOR THE VRA8 BLOG SERIES & WEBINAR

vRealize Automation is a lot like that.  Whether it’s frequently deployed common workloads, special purpose blueprints that are used a few times a month, quarterly, or a handful or fewer times a year, or software customizations specific to vRA, you have to identify everything that will require hand-holding when you begin the migration from vRA7 to vRA8. The good news is that, unlike your bank, VMware does offer a migration assessment tool to help you determine if your blueprints are ready to be migrated from vRA7 to vRA8. As of this writing, we have not yet learned if the migration assessment tool will determine if your customizations and workloads are ready for migration.

Read the full article here.

Posted on

Road to Automation with VMware vRA – vRA Design Part 1

GSS has decided on a number of design considerations for their vRA implementation.  GSS is currently using a consumption based model for their resource allocation.  They don’t pre-reserve any amount of resources for specific groups within the organization.  GSS feels their current consumption model allows them to more efficiently manage their resources.  It also prevents them from having pockets of idol resources that may never get used.  Based on this utilization model GSS will be implementing the following elements within vRA.

GSS  considered having a business group for each environment (Dev, Test, Stage, and Production).  To evaluate how they would like to proceed they asked to have 5 initial tenants created.  One for each of their environments and one to evaluate a collapsed model of all environments in one group.

Business Groups

  •  Development – All Developers across all groups within GSS
  • Test – All QA engineers within GSS
  • Stage – All production teams
  • Production – All Production teams
  • Gregarious – All Dev, QA, and Production teams

Continue reading “Road to Automation with VMware vRA – vRA Design Part 1”

Posted on

Road to Automation with VMware vRA – GSS Company Profile

In my previous article The Road to automation with VMware vRA I discussed I would be published a company profile for my fictitious company GSS.  In this article we will be digging into GSS to take a look at where it is today, its challenges, processes, systems, and automation use cases.

Company: (GSS) Gregarious Simulation Systems
Profile: Successful Video Game Manufacturer
Employees: 1200+
IT Staff: 80+
vSphere Sockets: 200+
Managed VMs: 3000+
Server Build Team: 12
Environments: Development, Test, Stage, Production

Continue reading “Road to Automation with VMware vRA – GSS Company Profile”

Posted on

The road to automation with VMware vRA

I think we need to take a few steps back and focus on vRA architecture and design.  I’ve had many questions, requests, and discussions with some of my readers on this topic.  Implementing vRA can lead to many rewarding outcomes, but as some have discovered it can also lead to aggravating outcomes if not designed properly upfront.

At first it can seem very straight forward. Create some endpoints, groups, reservations, and blueprints.  Sprinkle in some integrations for custom hostname, IPAM, DNS and AD and you are on your way to fully automating your workload deployments, right?  Not exactly.  You can certainly do this and at first it will seem amazing, but as you mature and start to scale out your new catalog of services the lack of up front design and planning will quickly start to reveal itself.

Continue reading “The road to automation with VMware vRA”

Posted on

vRA 7.3 – Configuring SovLabs Custom Naming Module

Many of you have utilized the Custom Hostname module that has been made available by Tom Bonanno here on Dailyhypervisor.  Those that use have probably noticed that it is no longer maintained.  This is because there are supportable modules available like the one I’m writing about now by SovLabs.  The Sovlabs module offers more flexibility and is a supported product making it a best of breed solution for this task.  Whats even better is their is a common framework that exists within the SovLabs platform that greatly extends the capabilities of each module.  More of the framework to come.  For now let’s go ahead and configure the custom hostname module.

Within the SovLabs custom naming module hostnames are broken in to two parts.  A Naming Sequence and a Naming Standard.

Naming Sequences

Naming sequences are exactly exactly what they sound like.  They basically define how are we going to sequence the names that are created.  Sounds basic right?  Well SovLabs has taken sequencing to a whole new level.  Most of you are probably familiar with using a standard decimal based sequence that might look like host001, host002, and so on.  SovLabs has added the ability to use HexaDecimal, Octal, and Pattern based sequences for your naming needs.  Pattern based sequences are insanely powerful.   Pattern naming sequences can contain Decimal, HexaDecimal, Octal, Binary, and Alpha.  Below are an examples of what you can achieve with Pattern Based naming sequences:
Continue reading “vRA 7.3 – Configuring SovLabs Custom Naming Module”