vRealize Automation 7 – Part 4, Initial Config as-a-service

We’ve discussed VMware’s focus on the UX and Time-to-Value (TTV) with vRA 7’s much-improved Deployment Architecture and the new Deployment Wizard, which automates the end-to-end deployment for for monolithic or distributed vRA implementations. This alone will drastically change the perceived complexity of installing the solution. But now that we’ve got that out of the way, why not take it one step further?

Once vRA is installed, there is still a significant amount of initial configuration and logic building to be done. While this allows customers to build a tailored solution based on their requirements and desired logic, it wasn’t very POC or quick-start friendly. It can take an experienced vRA admin another hour or so of configuration before being able to log in and request/deploy the first IaaS machine. For the inexperienced POC’er, this can be a brutal process no matter how well VMware attempts to document each step. In the spirit of automating automation and improving the quality of life for the average vRA admin, VMware has delivered a clever way to quickly tackle this. It’s called XaaS (aka anything-as-a-service, previously referred to as the Advanced Service Designer). In short, it’s an XaaS form and a set of vRO workflows that help vRA deliver itself as a service.…

vRealize Automation 7 – Part 3.1, Deployment Wizard Video

In part 3 of this series I provided an overview of vRA 7’s new deployment wizard – an addition that will significantly increase the time-to-value (TTV) by aiming to quickly deploy vRA regardless if it’s for a minimal (monolithic) or enterprise (distributed) implementation.  I cannot emphasize enough how critical the deployment wizard (along with the new deployment architecture) will be for removing the perceived complexity of getting vRA stood up.  Competitively, this sets a new standard for how to implement any enterprise solution and will certainly allow vRA to shine above the rest (but enough about that).

Below is a video of the deployment wizard walking through a minimal implementation.  It is important to note that vRA 7 has yet to GA, so some of the automation options and the UI itself can be tweaked between the current beta code and eventual GA builds.

(The screen capture is sped up 2.5X and some long wait periods have been clipped)

vRA 7 Deployment Wizard – FAST from @virtualjad on Vimeo.

The wizard will provide a choice of a minimal (POC, small) or enterprise (HA, distributed) deployment then, based on the desired deployment type, walks the admin through a series of configuration details needed for the various working parts of vRA, including all the windows-based IaaS components and dependencies.…

vRealize Automation 7 – Part 3, The Deployment Wizard

Remember that time you downloaded vRA (or vCAC) and tried to install it on your own? After some frustration and head-scratching, you turn to documentation, blogs, events, and a variety of guides provided by the community. Eventually everything starts looking good as you’re able to get passed the install and into initial configuration. vRA 6.x’s implementation involves a series of appliance deployments, VAMI configurations, prerequisite headaches, and installation of several IaaS components on windows hosts. Taking that to a distributed, highly-available configuration was a whole different story with the added complexities of deploying several additional systems, clustering configurations, external dependencies, and a whole other set of prerequisites. Of course none of this is unique to vRA — many enterprise solutions will take weeks or months to deploy in a production-ready state. There are many complexities expected of a cloud management platform that is nested at the center of an enterprise ecosystem. While the end-to-end implementation of vRA has come a long way, there was still a lot to be desired. Fortunately, that desire was understood…and a solution was brewing.

Continuing with the theme of redefining the user experience, vRA 7’s new deployment wizard takes time-to-value to a whole new level.…

vRealize Automation 7 – Part 2, Deployment Architectures

VMware has been tackling several customer pain points when it comes to deploying and configuring vRA (6.x). But let’s get this out of the way — the ratio of level of effort vs. product capabilities make the time investment quite worth it at the end of the day (at least i think so!).  In the overview post (Part 1), I mentioned the massive focus on overall UX improvements in vRA 7. While the new deployment wizard absolutely changes the perception of complexity and takes all the work out of the admin’s hands, the reduced deployment footprint is equally important and will drastically reduce operational overhead and time to implementation. That is especially the case for distributed architectures that can grow upwards of 20+ machines. Let’s change that, shall we?…

vRA 6.x Deployment Architecture

In addition to several external dependancies, vRA 6.x requires various internal/embedded services to be taken externally for high availability. The services embedded in the virtual appliance include vRealize Orchestrator, the vPostgres DB, and the vRA framework services themselves. An external Identity Appliance (SSO) is required for authentication (vCenter SSO also an option). And, finally, the optional App Services VA for app authoring.

For distributed architectures, the components include at least 2 load-balanced vRA VA’s, an external pair of clustered vPostgres DB’s, external clustered vRO pair, a pair of [vCenter] SSO’s (the Identity Appliance does not support an HA configuration), and a single ill-fated App Services VA, which also does not support an HA setup.…

Larger Stage, Louder Mic

Close your eyes and think of something you really want — whether it’s something you want to accomplish, a must-have “toy”, or anything you wish you had but weren’t really sure how you’d get it.  Sometimes that incredible thing you get isn’t something you were actively pursuing.  Sometimes it is.  I closed my eyes and did this very exercise a little less than 6 years ago.  I was at a great point in my career at Lockheed Martin and had established myself relatively well.  But I was ready for that thing.  So I closed my eyes…and when I opened them, I found myself sitting in my very own cube (with a view!) at VMware’s Public Sector HQ in Reston, VA.  I was suddenly at my favorite little tech company that had already changed the world (at least once)…and was ramping up to do it again.

Okay so maybe it didn’t happen exactly like that. There were a few interviews and several great conversations, but never did anyone have to do any convincing…I wanted in!  Ever since I joined VMware back in 2009, I knew I was suddenly a part of something huge.  My Lockheed career had been such an incredible period of my life and a significant part of developing my skills up to that point, but I often found myself wanting to grow my career and head in a direction that I wasn’t sure Lockheed was ready to support.  …

A Quick Lesson on vRA Entitlements

vRealize Automation provides a ton of granularity for roles and permissions, service availability, lifecycle management (e.g. day-2 operations). It essentially boils down to a set of logic that defines who can see and do any given task on any given resource. This can be as simple as a handful of configurations, or get as complex as you want it to be.

vRA’s Entitlements feature is just one of many ways to add governance and additional controls to your environment. Entitlements allow admins to create a set of policies that determine which services any given consumer can deploy and how they can [lifecycle] manage their services post-provisioning. The following entitlement options are available per Business Group User or Group.

  • IaaS Blueprints
  • PaaS / AppServices Blueprints
  • XaaS Services
  • Actions / Custom Actions (Day 2 Operations)
  • Service Catalogs
  • Approval Policies

Entitlements are created and managed under Catalog Management (Administration tab -> Catalog Management -> Entitlements) for all available services. It is important to note that entitlements are a REQUIRED function for service delivery (e.g. all services must be entitled at some level before they are available for consumption). Since this isn’t a HOW-TO post (see the vRA Live Install and Config videos and/or the vRA 6.0 POC Guide for a detailed how-to), here’s a summary of how to get from here to there…

 

 

 

 

 

 

 

 

 

 

Once an Entitlement is created, there are several options that will help you fine-tune exactly what gets entitled, who this entitlement effects, which actions are available, and whether or not component-level approval policies are in the mix.…

Increasing vRA’s Concurrent Provisioning Operations

I get this question on a weekly basis (at least) – how many concurrent provisioning operations can vRA handle?
…and as soon as I say “2”, i get the [expected] follow up – how can I change that to something ridiculous?

Here’s how:

But first, let’s revisit the blanket statements above because they’re missing a lot of details. The REAL answer is “it depends”. Concurrency primarily depends on which Endpoint is configured, whether or not a proxy agent is used, and what the endpoint itself can handle. The vast majority of vRA customers have at least 1 vSphere Endpoint — which leverages a proxy agent — so I can confidently divulge the default concurrency of 2. Here’s a glimpse of those defaults…

  • Proxy Agent-based (vSphere, XEN, Hyper-V) – 2 per agent
  • DEM-based (all other supported endpoints) – no fixed limit (sort of, see below)

There are a few additional considerations:

  • The number of concurrent workflows per DEM instance. That number is 15 (per DEM).
  • While DEM-based endpoints have no theoretical limit, the DEM workflow concurrency of 15 (per DEM) does apply.
  • Endpoint limits are at play (that is, the endpoints themselves). For example, vSphere 6 can handle 8 concurrent operations by default.

ProTip – Changing a Provisioned Machine’s Owner in vRA

This one comes up all the time…a Business Group Manager (see prereqs) requests an entitled machine, does XYZ configuration on it post-provisioning, then wants to transfer it on to someone else for ownership (whatever the reason that may be).

There are a couple of options for changing the Machine Owner in vRA — during Request, during a Bulk Import (using the Infrastructure Organizer, or by Reconfiguring the machine. You can also allow an Approver to change ownership mid-flight, but that’s a bit more involved.

To change a provisioned [IaaS] machine’s owner by using the “Reconfigure” Day-2 operation…

Some Prerequisites:

  • you must be a Business Group Manager to make the change
  • you must have “Reconfigure” action enabled (via entitlements)
  • the NEW owner must be a Business Group User

Steps:

  1. Log in to vRA with using an account with “Business Group Manager” role
  2. Navigate to the Items tab
  3. Click to open the desired Machine from the list (NOTE: Business Group Managers can manage machines from all users within the business group and can change change the owner of any visible machine.