VMware’s much-anticipated announcement of vRealize Automation 7.0 (vRA 7) claimed the spotlight at VMworld EMEA 2015 in Barcelona. The cloud management team had the opportunity to hosts several vRA sessions throughout the week to divulge many of the “spotlight innovations” being delivered with vRA 7. Now it’s finally time to share with all of you the cloud management goodness that’s been brewing at VMware. This overview post will cover all the newly announced spotlight innovations of vRealize Automation 7.0 to get you acclimated. Future posts will dig deeper into individual capabilities, value-focused use cases, and several additional features we’re all excited about.
Spotlight #1 – Deployment and Initial Configuration
vRA 7 focuses a lot on the user experience (UX), starting with one of the most critical — Deploying the solution — then the second most critical, configuring it. Following through with the promise of a more streamlined deployment experience, we made a huge splash at VMworld Barcelona with the debut of the wizard-driven and completely automated installation of the entire platform and automated initial configuration. And all of this in a significantly reduced deployment architecture.
Deployment Architecture – The overall footprint of vRA 7 has been drastically reduced. For a typical highly-available implementation, you would need at least 8 virtual appliances (VA’s), at least 4 load balancer virtual IP’s (VIP’s), and an SSL cert for each just to cover the core services (not including IaaS/windows components and the external App Services VA). In contrast, vRA 7’s deployment architecture brings that all down to a single pair of VA’s for core services. Once deployed, just 2 load-balanced VA’s will deliver vRA’s framework services, Identity Manager (SSO/vIDM), vPostgres DB, vRO, and RabbitMQ — all clustered and configurable behind a single load balance VIP and a single SSL cert. All that goodness, now down to 2 VA’s and all done automatically (!) during deployment.
While the IaaS (.net) components remain external, several pieces have moved to the VA. This will continue to be the case over time as more and more services make it over — eventually eliminating the Windows dependencies all together. So, for now — and in the spirit of UX — it’s all about making even those components a seamless part of the deployment. Read on…
Wizard-Driven Automated Deployment – This one tops the charts as one of the most significant enhancements of the overall platform. Starting with the single OVA download deployed to vSphere, admins log in to the Virtual Appliance Management Interface (VAMI) and bam!…the Deployment Wizard automatically starts.
Once kicked off, the admin is walked through a series of inputs needed for the various working parts of vRA, including the external windows .net dependencies. This will apply to both monolithic (POC’s, small environments) and highly-available and distributed enterprise implementations (and everything in between). For HA deployments, all the core components (above) are automatically configured and clustered based on inputs. The windows components (Model Manager, Web Services, DEMs, and Agents) are automatically pushed to available windows servers available in the environment. This is all based on desired placement by the admin via the wizard.
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. For HA deployments, all the core components are automatically configured and made highly-available based on these inputs.
The wizard also checks for prerequisites and allows the admin to validate at each step to make sure all entries are good to go. Once all the inputs are complete, one final end-to-end validation kicks off, and then installation begins. In a POC deployment, time from VAMI login to completely implemented is clocked at somewhere around 20 mins. For an HA deployment, end-to-end config will be under a couple of hours (results may vary).
Automated Initial Configuration – As if the above hasn’t already put a smile on your face (or, at the very least, a small smirk), we weren’t quite done with initial UX. During the deployment wizard, admins will have an option to select an option to automatically build and configure an initial tenant (default “vsphere.local” or create new). This includes configuring all the logic needed to allow a user to log in and request a machine — even automatically running an endpoint inventory and allowing the admin to select witch templates they want to create blueprints from. The initial config wizard does all this in under 10 mins (can be more, depending on several factors of course).
In summary, OVA to logging in to an IaaS catalog can be done in under an hour total. This is a big deal. I’ll dig a lot deeper into each of this in subsequent posts
Spotlight #2 – Identity Management w/vIDM
vIDM has been embedded into vRA 7 for all things authentication and access controls, providing OOTB support for Two-Factor / Multi-Factor auth providers, SAML 2.0 token support, and policy-based access controls. This is significant move and in many cases can be the difference between vRA in a POC and vRA in production. Then there’s the issue of scalability — vIDM is tested to scale at millions of objects, syncs all desired users and groups to the local DB, and allows for granular controls over what to sync (e.g. sync everything or just the users of a specific OU nested deep inside AD). It also allows you to create sync filters (e.g. “entire directory except any user that contains admin”).
Finally, vIDM adds per-tenant branding capabilities to the login screen…point and click branding of not just the backdrop when you log in, but also the overall UI (color scheme, naming, branding logos, footer and header, etc).
As mentioned before, the vIDM components are embedded into the vRA VA and are automatically clustered by the wizard in an HA deployment. Customers moving to vRA 7 get vIDM fully integrated and at no additional cost (i.e. no need to license the vIDM solution separately).
Spotlight #3 – Converged Blueprint Designer
Essentially the Converged Blueprint (CBP) Designer is exactly how it sounds. Blueprints are now built on a dynamic drag-n-drop design canvas, allowing admins to choose any supported components, drag them on to the canvas, build dependencies, and publish the finished product to the catalog. The supported components include machine shells for all the supported OOTB platforms, software components, endpoint networks, NSX-provided networks, XaaS components, and even other blueprints that have already been published (yes, nested blueprints). Once dragged over, the admin can build the necessarily logic and any needed integrations for each component of that particular service.
Application Authoring — The CBP canvas is the one-stop shop for all “traditional” (IaaS) single-machine and multi-machine blueprint authoring as well as application authoring. That’s right, the external App Services (a.k.a. Application Director, AppD) engine, and all of it’s perceived complexities, is dead. App authoring is now completely done from within the CBP canvas with the same drag-and-drop capability.
Dynamic Networking & Security (NSX) — From a networking perspective, NSX and everything it brings into vRA 6.x today applies to vRA 7, but now it’s all done with the ease of drag-n-drop canvas design. vRA 7 will consume and automate more of NSX than ever before, including the ability to dynamically build on-demand network services (load balancers, routed networks, and NAT). The canvas also allows the drag-n-drop of NSX security groups (existing or on-demand) and will support app-centric isolation.
Incorporating XaaS Services – The Advanced Service Designer (ASD) has been renamed simply to XaaS Designer. Building XaaS services by leveraging vRO continues to be “killer feature”, but now all XaaS services you build can also be dropped onto a converged blueprint, incorporating those whatever services with IaaS and App designs…and even building dependancies, binding attributes, and more. Killer feature is an understatement.
Blueprints as Code — Finally, all blueprints can now be exported as YAML code using the CloudClient. Once exported, admins can edit/change/manipulate the content how ever they see fit, then import back into vRA as a new blueprint. And since it’s just text — the YAML can be sent anywhere, edited, and imported into disparate vRA environments.
Spotlight #4 – Lifecycle Extensibility, Event Broker Service
vRA 7 introduces a message bus integrated extensibility engine (RabbitMQ) called the Event Broker Service (EBS), which provides UI-driven extensibility options for some serious lifecycle state automation options, among others. EBS replaces the “legacy” .net-based Cloud Development Kit (CDK) for complex extensibility and integration use cases. This provides a centralized means of integrating and automating external systems as part of a machine’s lifecycle by leveraging vRealize Orchestrator. While all the traditional extensibility goodies (custom properties, property groups, wfstubs, etc) are still around, EBS helps eliminate much of the complexities and multiple admin points of vRA 6.x.
Centralized Extensibility – The Event Broker is available inside the vRA 7 UI under the Administration tab. In EBS, an admin creates a Subscription that defines one or more trigger events to listen for. This can be as a global policy for all events or as granular as “when a-b-c and e-f-g happen for any machine that starts with h-i-j at a very specific service state, call workflow x-y-z…”….and that happens independent of any custom property or workflow stub called out at the blueprint. Once the subscription is created and activated, it becomes immediately enforced globally. A trigger can be any number of events occurring on the message bus and the policy’s response can be to call any given workflow (or set of workflows) available in vRO.
Blocking Tasks – EBS can also trigger a blocking task, which can stop a given workflow (e.g. during approvals) and hand information off to an external system for processing (e.g. a corporate governance engine). Once EBS receives a response, it can determine how to proceed with the provisioning request.
EBS addresses one of the biggest problems of extensibility — management complexity — by bringing the policy engine directly into the vRA 7 UI and providing a centralized means of extending vRA into the ecosystem. While some of the more traditional components still exist, their use in tandem with EBS can solve more complex use cases in a much more streamlined solution.
Final Thoughts
While vRA 7 brings with it a slew of new technologies and features, these spotlight innovations are what will truly differentiate vRA, while providing a simplified path to implementation and overall manageability. Stay tuned for more great content, special events, and deep-dives as we near vRA 7’s GA release.
