An Early Cloud

In my previous life as a Solutions Architect at EMC, I led a project at a large Enterprise account to deliver a self-service, on-demand, elastic infrastructure.  The solution included a web portal where lines of business (LOB) could request compute, network, and storage resources; the request would be automatically routed through the appropriate management chain and upon approval, resources would be automatically provisioned.  We were evern able to implement a chargeback system that allowed the LOB to choose and to pay for resources with different pricing, based on service levels.  Not an easy feat, even if we had used the Cloud enabling technologies that exists today, such as VMware’s vCloud Suite, OpenStack, CloudStack, or Virtustream xStream.  It was an even more daunting task given that the project took place back in 2002 and all compute resources at this customer were Solaris or Windows servers, with no enterprise virtualization capabilities available.

One key enabler for this early “Cloud” was the decision by the customer to standardize on a specific hardware and software stack.  Through a long and sometimes painful remediation process, they were able to reduce their configuration options to a manageable number of OS versions and hardware firmware.  This allowed us to abstract the stack to a set of compute, network, and storage resources that could be presented to users in a service catalog.  The other enabler were hardware APIs that we could script to and integrate with as part of a provisioning workflow.  This provisioning workflow itself was called out by other scripts as part of the resource request and approval workflow.

The Problems

There were, however, a number of issues with the approach that was taken to build this nascent Cloud:

• Because resources were not virtualized and much of the hardware APIs were incomplete, we were able to provision new resources but could not easily decommission or retire those resources when they were no longer needed.
• Since there was no integration between the various components in the stack and no open APIs available, everything had to be duct taped together with scripts that would often break and was difficult to support.
• Any time one of the vendors that supplied a component in the stack upgraded his technology, major rewrites had to be done to the scripts.  My customer estimated that they spent between $500K to $1 million a year to maintain the web portal and all the underlying scripts.
• Since no less than 6 vendors supplied component that made up the infrastructure stack, it seemed the resolution of every issue involved major churn and much vendor finger-pointing.  Certifying new software and firmware was a major undertaking because of the integration testing that my customer had to do on a regular basis.
• Since every component had its own SNMP MIBs and APIs, an assortment of monitoring tools were required to mange the infrastructure.  Root cause analysis was a major undertaking as well since they would receiving multiple alerts from every component with no easy way to do event correlation.

Introducing…. Vision Intelligent Operations

As part of today’s VCE Virtual Launch, we unveiled the new Vision Intelligent Operations for enabling true converged infrastructure systems management of a Vblock.  So what is Vision Intelligent Operations?

Let me begin by explaining what it isn’t.  Vision Intelligent Operations is NOT another management product with a user console, such as EMC UIM, EMC Unisphere, Cisco UCS Manager, or VMware vCenter.  It is more accurate to think of Vision Intelligent Operations as a set of APIs and system libraries for the Vblock that enable existing management tools to visualize and mange a Vblock as an integrated system, and not just as a set of disparate components.  Vision Intelligent Operations abstracts the underlying components of the Vblock and by doing so, masks the complexities of those components from the northbound management layer.

The immediate benefits of this approach include the following:

• We can provide an integrated view of the Vblock and all events related to the Vblock.  This simplifies event management and will allow the management system to correlate events from all the Vblock components to expedite root cause analysis.
• We can provide integrated health and compliance monitoring that understands the relationships between all the components and how they impact the overall health of the Vblock.
• We can map the current firmware running in all the components of a Vblock to the VCE Release Matrix to ensure compliance of the entire infrastructure stack.
• By exposing a single set of Vblock APIs to the management system, we obviate the need for constant changes to be made at that layer when software and firmware changes are introduced in the Vblock.  Instead VCE will update the Vision Intelligent Operations APIs and libraries and mask those changes from the management software.

As I mentioned, Vision Intelligent Operations is not a management software with a user console.  Instead we abstract the Vblock and present it via system APIs to a northbound management system.  Because the Vision Intelligent Operations software uses open REST APIs, it can integrate with any management software that will write adapters and plugins that leverage these APIs.  The expectation is that we will see integration into management suites from our investor companies – VMware, Cisco, and EMC; we also expact to integrate with software from our ISV partners, such as BMC and CA.  First out of the gate will be integration with VMware, including a Vision Intelligent Operations plugin for vCenter and an adapter for vCenter Operations Manager (vC Ops).

The plugin will allow vCenter to visualize and to monitor a Vblock as an integrated converged infrastructure system in a way that it could not do with a reference architecture.  The vC Ops adapter will present users with health, capacity, and risk badges for the entire Vblock as an integrated system and not just the virtual machines that sit on top of the hardware stack.

The Future

You will note that the first release of Vision Intelligetn Operations is focused on visualiazation and monitoring.  However, as I discussed in a previous blog post on the Software-Defined-Datacenter, the true value of a converged infrastructure system is fully realized when it can be provisioned and changed, programmatically and dynamically, in response to changing requirements.  The long-term strategy is that the APIs and libraries exposed via Vision Intelligent Operations will allow the northbound managment system to control and perform this function. So look for more to come from VCE.

Related articles

• Delivering The Cloud On A Vblock: A Story In Pictures (varchitectmusings.com)
• An Update From My Friends At VCE (chucksblog.emc.com)
• VCE Vblock Systems Selected As Converged Infrastructure For New GOV.UK Website (virtual-strategy.com)