Vblock + VISION + UIM

We’ve learnt a lot over the 3-ish years that Vblock has been on the market.   The core “why” people choose to deploy on Vblock or Vblock-like consumption/support models is fundamentally about hyper-standardization to commoditize the whole infrastructure (all the way up to the hypervisor) stack underneath the application/automation stack.

A lot of VCE engineering goes into the standard, and maintaining the standard.

Learning comes best when there are stumbles – there are things I think we (here I mean the collective “we” – EMC, VMware, Cisco, VCE) could have done better – and we’re working to always do better.

In the early days – we took the first stabs at creating software that helped “manage the standard”, creating service profiles across the whole stack.   Unified Infrastructure Manager (UIM) GAed way back in 2009 (check out this post), and targeted this part of the value.  It was never an “end-user self-service portal”, it was always about extending the idea of “Service Templates” that Cisco UCS does so well – and extending it all the way up to the things that vCloud Director/vCloud Automation Center (or today, Openstack) would consume – across compute/network/storage/hypervisor layer.

There  were 2 ways I think we made mistakes:

1. The very low-level baseline configuration was harder than we expected.   Think of this as: “what happens if someone pops in a non-compliant blade, or disk?”; or “what happens if someone logs into an element manager and borks things up?”; and finally, “how do you configure before the APIs for components come up?”  These things needed physical connectivity to components – and just as importantly, needed to be owned by the people who manufacture Vblocks, which is VCE.   Without that – UIM would always lag critical baseline changes in Vblocks standards and components.
2. People didn’t really understand what Vblocks and UIM (and EMC) didn’t do.   It’s always important to note the boundaries – both extremes of the spectrum.   UIM was not (and never was) – an end-user self service portal, or general purpose automation tool – (think of the category of vCAC/vCD, or CIAC/Cloupia, OpenStack + Dashboard).

VCE has taken on the task of the solving the first gap/error via VCE Vision (think of this as a low-level BIOS-like management function that aggregates up the lowest level of automation).  I think VCE Vision does it better than UIM ever did.   Vision takes over the lowest level functions (and where necessary physical configuration)

EMC has taken on the task of the second gap by evolving UIM – squarely focusing it on the service automation layer above Vision, and below the end-user portal and general purpose automation stacks.

The latest UIM release (3.2 SP1) has this critical VCE Vision integration, and you can see below how it integrates with VCE Vision which really demonstrates how compliance with VCE standards can be represented and resolved.

BTW – if you want to play with this yourself – there’s a vLab instance up now – check it out here http://portal.demoemc.com

This Lab will allow you to demonstrate EMC Unified Infrastructure Manager (UIM) 3.2. It provides an introduction to UIM, the initial discovery of Vblock system, Service Offering creation and provisioning and a set of use cases: Creating an infrastructure service offering + Provisioning services + Viewing alerts from Vblock system components and launching topology views

Using UIM?   Interested in this?   What else would the full stack  (vCAC/vCOPS/vCD or Openstack + VCE Vision + Vblock) need?   Certainly backup… You really should check out what we’re going to do at the HoL at VMworld this year… :-)