Private Cloud Stacks

Interest in private clouds and converged infrastructure continues to grow because organizations can rapidly deploy applications in a scalable fashion. Whether the goal be IT cost reduction, business agility, or any number of other benefits of smarter IT service delivery application delivery. That being said applications don't run on their own and infrastructure is a major consideration for how those applications will run.

When deciding on infrastructure there is always the traditional option of assessing, designing and building the infrastructure piecemeal internally or with a trusted reseller or systems integrator. This approach has advantages. Depending on legacy architecture and business objectives, do-it-yourself fits best in cases organizations that significant legacy equipment with remaining lifecycle, specific vendor ties or loyalties, dominant skill sets in specific vendor hardware, or highly customized requirements.

Another option that is being pushed by the major IT giants is integrated stack architectures. Integrated stacks are some level of vendor integration, testing and certification of various hardware and software components which can include: compute, storage, network, virtualization, automation, and orchestration. Integrated stacks come in many shapes and forms, so let's take a quick dive into the general options:

Single vendor stacks integrate hardware and software from a single IT vendor. Two examples of this are HP BladeSystem and Oracle's Exalogic. Matrix is HP's BladeSystem coupled with HP storage and networking components. Additionally Matrix integrates HP's Cloud Service Automation which means that Matrix 'out-of-the-box' is very close to the full vision of a private cloud. Oracle's Exalogic offering is highly tailored toward Java, and other Oracle focused middleware and applications. It is constructed on Oracle hardware (formerly Sun), middleware, and software. With the automation and orchestration in place within Exalogic , it is very close to full private cloud functionality.Multi-Vendor Approach

The multi-vendor approach bundles hardware and software components from several manufacturers into a joint solution with some level of integration testing and certification done by the vendors. Two examples of this are VBlock and FlexPod.

Vblock is a combination of Cisco networking and compute, EMC storage and VMware virtualization software. Vblock is bundled with EMC's Unified Infrastructure Manager software which provides a level of automation and a single point of management for most of the infrastructure. Vblock is supported and tested by The VCE Company which was created by the three parent OEMs as a delivery/support model for Vblock as well as a way to drive future joint integration and advance the solution as whole.

FlexPod is a joint solution between NetApp, and Cisco to provide a tightly coupled converged infrastructure that can support multiple private cloud and application environments. FlexPods come in many flavors such as VMware server virtualization, Citrix VDI infrastructures or tailored to Microsoft environments like SharePoint, Exchange and SQL. The base FlexPod solution is not bundled with automation/orchestration software which places it below the other examples for private cloud readiness out of the box, but by doing so enables customers to choose the automation/orchestration tools that best fit their needs.

Both approaches have the potential to accelerate a customer journey to private cloud or cloud like service delivery. This is achieved by the testing, certification and integration that is taken care of by the vendor and the confidence/risk-reduction of running on a proven infrastructure.The Reality

There are pros and cons to both approaches dependent on the business drivers and challenges. Through my experience I've found greater value in the multi-vendor approach as long as two challenges are addressed. The first is the delivery model - Does it show up as a single solution or a bunch of boxes? If not the customer will require the knowledge and expertise to integrate the components and properly configure them to the architectural standards, which can slow adoption and increase risk. The second is the support model. Do I have single number support and appropriate knowledge levels from support personnel? Without this the customer will spend unnecessary cycles troubleshooting issues and tracking multiple support tickets amongst the various vendors involved. Kingman Tang and I discussed this topic at length.

The issue that tends to arise with the single vendor approach is that a single vendor rarely if ever has the best-in-class hardware and software required to build this level of integrated platform. For example software only (or mostly software only) vendors such as Citrix and VMware dominate server and desktop virtualization and will be needed in many solutions breaking the 'single-vendor' spell at the base infrastructure level. Additionally solutions like Exalogic leave out the majority of the traditional x86 applications and Windows based servers leaving you with a cloud silo. That being said there are customers who prefer the model of a single trusted vendor providing the infrastructure or most of it, and thus there is value in that model.

Another key point is that just because automation/orchestration software is included in a product offering doesn't mean it's ready to go 'out-of-the-box.' Orchestration and automation are very custom software sets that typically require significant service hours to integrate and tailor to each individual environment.

Integrated offerings such as the ones above can greatly increase the pace of private cloud adoption or scale out of new more flexible services but it is important to carefully assess which approach correctly fits the goals and objectives of the organization.

Disclaimer: In my primary role I work with several products from each of the vendors mentioned but they are used here for example purposes only and are not an endorsement of the products or vendors.