This last fortnight there’s been a cacophonyof hyperbole and at times marketing fluff from vendors and analysts withregards to Reference Architectures and Converged Infrastructures. As IBM launchedPureSystems, NetApp & Cisco decided it was also a good time to reiteratetheir strong partnership with FlexPod.  In the midst of this, EMC decidedto release their new and rather salaciously titled VSPEX. From the remnants andashes of all these new product names and fancy launch conferences, theresultant war blogs and Twitterati battles ensued. As I poignantly watched onfrom the trenches in an almost Siegfried Sassoon moment, it was quicklybecoming evident that there was now an even more ambiguous understanding ofwhat distinguishes a Converged Infrastructure from a Reference Architecture,what it’s relation was with the Private Cloud and more importantly whether you,the end user should even care.

There’s a huge and justified commotion in theindustry over Private Cloud because with lower costs, reduced complexity andgreater data center agility, the advantages are compelling for any businesslooking to streamline and optimize its IT. In the pursuit of attaining suchbenefits and ensuring a successful Private Cloud deployment, one of the mostcritical components that need to be considered is that of the infrastructureand its underlying resource pools. With resource pools being the foundation ofrapid elasticity and instantaneous provisioning, a Private Cloud’s successultimately depends on the stability, reliability, scalability and performanceof its infrastructure. With existent datacenters commonly accommodating legacyservers that require a refresh or new multiprocessor servers that are entrenchedbetween an old and insufficient network infrastructure, one of the mainchallenges of a Private Cloud deployment is how to upgrade it withoutintroducing risk. With this challenge and the industry’s pressing need for aneconomically viable answer, the solution was quickly conceived and baptized as“Converged Infrastructure”.  Sadly like all great ideas and concepts,competition and marketing fluff quickly tainted the lucidity of such an obvioussolution by introducing other terms such as “Reference Architectures” and“Single Stack Solutions”. Even more confusing was the launch of vendor productsthat used such terms synonymously, together or as separate distinct entities.So what exactly differentiates these terms and which is the best solution tomeet the infrastructure challenge of a Private Cloud deployment?

EMC's new VSPEX - Reference Architecture with a variety of options of components

Reference Architectures for all intents andpurposes are essentially just whitepaper-based solutions that are derived frompreviously successful configurations. Using various vendor solutions and leveragingtheir mutual partnerships & alliances, Reference Architectures aretypically integrated and validated platforms built from server, network andstorage components with an overlying hypervisor. NetApp’s FlexPod and EMC’sVSPEX fall into this category and both invariably point to their flexibility asa major benefit as they enable end users to mix andmatch as long as there remains a resemblance to the reference. With open APIsto various management tools, Reference Architectures are cleverly marketed as aquick, easy to deploy and risk free infrastructure solution for Private Clouds.Indeed Reference Architectures are a great solution for a low budget SMB thatis looking to introduce itself to the world of Cloud. As for a company that iseither in or bordering on the Enterprise space and looking to seriously deploytheir workloads onto a Private Cloud, it's important to remember that sometimesthings that are great on paper can still end up being a horrible mess inreality – anyone who's watched Lynch's Dune can pay testament to that.

The difficulty with Reference Architectures is that fundamentally they still have no hardened solution configurationparameters and ironically what they term an advantage i.e. flexibility, isactually their main flaw as their piece by piece approach of using solutionsfrom many different vendors merely masquerades the same old problems. Due tobeing whitepaper solutions, integration of specific components is onlydocumented as a high level overview with component ‘a’ being detailed ascompatible with component ‘c’. With regards to the specifics and how thesecomponents integrate in detail, these are simply not available or realizeduntil the Reference Architecture is cobbled together by the end user, whoultimately assumes all of the risk and financial obligation to ensure it notonly works correctly but is also performing at optimum levels. This haphazardtrial and error approach is counterproductive to the accelerated,pre-integrated, pretested and optimized model that is required by theinfrastructure of a Private Cloud.

Furthermore Reference Architectures are basedon static deployments of sizing and architecture that typically has littlerelation to the end users actual environment or needs, posing a problem wheneverreconfiguration or resizing is required. With end users being left to resizeand consequently reconfigure & reintegrate their solution, they also haveto constantly find a way to integrate their existing toolsets with the openAPIs. This subsequently eliminates a lot of the benefits associated with “quicktime to value” as many deployment projects get caught up in the quagmire ofsuch triviality. Added to this, once you’ve begun resizing or customizing yourarchitecture, you’ve actually made changes that area deviation from the proposed standard and hence no longer recognizable to theoriginal reference. This leads to the other complication with ReferenceArchitectures, namely support issues.

NetApp's FlexPod Reference Architecture uses Cisco UCS Blades & VMware

With more than 90% of support calls being related to logical configurationissues, they are more often than not an occurrence of bugs or incompatibilityissues. When the vendor has no responsibility or knowledge of that logicalbuild based on the fact that they meet your “requirements” to be flexible, thesituation doesn’t bode any better than when you have a traditionalinfrastructure deployment. Vendor finger pointingis one the most frustrating experiences you inevitably have to face whendeploying an IT infrastructure in the traditional way. Being on a 4am conferencecall during a Priority 1 with the different organizational silos and thenumerous vendors that make up the infrastructure is a painful experience I’vepersonally had to face. It’s not a pretty sight when you’re impatiently waitingfor a resolution while the networking company blames the firmware on theStorage and the Storage vendor blames the bugs with the servers while all thetime you are sitting their watching your CEO’s face turn into a tomato whilethe vein in his neck throbs incessantly.

When you log a support call for your reference architecture who is actually responsible? Is it the company youbought it from or one of the many manufacturers that you used to assemble yourself-built masterpiece? Furthermore which of those manufacturers or vendorswill take full responsibility when you’ve ended up building, implementing andcustomizing the architecture yourself? Even at the point ofdeployment, the Reference Architecture carries elements of ambiguity for theend user ranging from which software and firmware releases to run to who isresponsible for the regression testing of the logical build. For instance what if you decide to proactively update to one of yourcomponents’ latest firmware releases and then find out it’s not compatible withanother of your components? Who owns the risk? Also for example if you buy a“flexible” Reference Architecture from vendor X, how will vendor X be able todistinguish what it is you’ve actually deployed and how it’s configured withouthaving to spend an aeon on the phone doing a fact finding session, all whileyour key applications are down? Reference Architectures are great for atest environment or simple cheap and cheerful solution but using them as aplatform to take key applications to the Cloud reeks of more 4am conferencecalls and exploding tomatoes.

Oracle Exalogic - Virtualization with OracleVM not VMware

Single Stack Infrastructures on the other hand while also sometimes marketed as a Converged Infrastructure or a“flexible” Reference Architecture (or sometimes both!) are another completelydistinct offering in the market. These solutions are typically marketed as“All-in-one” solutions, and come in a various number of guises. Products suchas Oracle’s Exadata and Exalogic, Dell’s vStart, HP’s CloudSystem Matrix andIBM’s PureSystems are all examples of the Single Stack solution where thevendors have tightly defined software stacks above the virtualization layer.Such solutions will also combine a bundled infrastructure and service offeringsmaking them potential “Clouds in a Box”. While on the outset these seem idealand quick to deploy and manage, there are actually a number of challenges withthe Single Stack solution.

The first challenge is that the Single Stack willalways provide you their own inherent components regardless of whether they areinferior to other products in the market. So for example, instead of havingnetwork switches from the well established Cisco or Brocade, if you opt withthe HP solution you’re looking at HP’s ProCurve, 3Com, H3C and TippingPoint.Worse still is if you go with the Oracle stack you’re condemned to haveOracleVM as opposed to the market leading and technically superior VMware.Another challenge is that you’re also tied down to that one vendor and are nowa victim of vendor lock-in. Instead of just having infrastructure that will fityour existing software toolset and service management, you will inevitably haveto rip and replace these with the Single Stack’s product set. Additionallythese complex and non-integrated software and hardware stacks requiresignificant time to deploy and integrate, reducing a considerable amount of thevalue that comes from an accelerated deployment.

Read the original blog entry...

Published April 23, 2012 – Reads 3,788
Copyright © 2012 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.