Home | Opinion | Will EMC Leave Non-Vblock Customers Out In The Cold?

Will EMC Leave Non-Vblock Customers Out In The Cold?

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

Last Friday I was a guest on the latest Infosmack podcast, with special guest Chad Sakac.  One of the topics was Ionix Unified Infrastructure Manager 2.0 (initially in beta).  You can read more details in the press release, however in a nutshell, UIM is all about providing unified orchestration for deployment of virtualisation in a Vblock architecture.

I asked Chad the question – what happens if customers have heterogeneous environments?  The answer from Chad was “Good luck to them” – a comment I take to mean – you’re on your own.  Now Chad did and will point to the fact that there are vendors out there who provide 3rd party solutions equivalent to UIM in environments that are not pure VCE (VMware, Cisco, EMC), however is that a fair direction for EMC to take?

Personally, I feel that EMC are effectively telling customers that they adopt the Vblock model (and UIM), or they will be left out in the cold.  It’s an example of further moves to lock end users into their proprietary stack of technology.  However although Chad intimates that alternatives to UIM exist, unfortunately they will never be as good as UIM for one simple reason:

VMware, Cisco and EMC own and understand the APIs used to drive their products.  They can (and I suspect probably do) retain certain documentation that enables them to have a competitive advantage over 3rd party vendors attempting to add equivalent functionality.  In addition, they can also make microcode and software changes to those APIs to provide any feature that might be needed to make UIM a better product than their competitors.  This ability always gives them the edge over any other vendor looking to offer similar functionality to UIM.

Of course, why shouldn’t EMC/VMware & Cisco do this?  After all, they have the right to do anything with their products that they choose and far be it from me to tell any vendor what their product & marketing strategies should be.  But it is worth looking back to the attempts by many companies to offer unified storage management tools; no hardware or software vendor has yet provided a single unified storage management tool that works across heterogeneous environments.  Customers still retain multiple products for storage provisioning, in many cases continuing to make use of CLIs rather than graphical interfaces.  So, the chances of there being a successful generic virtualisation orchestration product out there are slim to none.

So what is the solution?  For EMC, their answer would be to take Vblock and UIM.  But what happens if you take that route and build all your processes around UIM, then decide to change your storage vendor?  At that point you have nowhere to go other than to re-engineer your entire orchestration process, creating a very high cost and barrier to change.

Here’s one other point to ponder; in February, EMC sold off a number of the Ionix tools to VMware.  So if these products were intended to be part of vCenter, why is UIM coming from EMC?  There’s one easy answer to this; if VMware sold the product, their other partners (like Netapp) could push for integration of their products into UIM.  By selling UIM as an EMC tool, this support will never happen and so Netapp are forced to either write their own tools or partner with 3rd party vendors.  In this way the VCE coalition can continue to control their market.

So do you think vendor lock-in is a good thing?

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • Pingback: Tweets that mention Will EMC Leave Non-Vblock Customers Out In The Cold? -- Topsy.com()

  • http://etherealmind.com EtherealMind

    And this is the part that I fear most about the “stack”.

    OTH, developing a management platform for multiple vendors is very difficult as implementation and architectures are often very different. Attempting to orchestrate widely different approaches to storage or networking or servers probably isn’t going to make money. For example, Cisco vFrame product failed for this reason.

    Perhaps when the products are established and core functions are working, they will work on third party integration.


  • http://virtualgeek.typepad.com Chad Sakac

    Chris, thanks for the post.

    Seriously though, that’s NOT what I said in the podcast, and people are welcome to listen to it and come to their own conclusion.

    I know you feel like your contribution is best by being argumentative/negative and positing conspiracy type thinking, but there’s a line I’d appreciate not being crossed – which is being directly misquoted.

    What I said on the call:

    1) VCE is additive, not substitutive for EMC, Cisco and VMware’s go to market. That is a simple idea. Let me explain it (which I did on the call).

    In the past, our “go to market” (aka how we sell and support customers) was 100% focused on “mix and match”. WE CONTINUE TO DO THAT. Sunk in? Has everyone got that? We do that by using standards, driving standards where none exist, having broad interop models, and making ALL our stuff accessible via APIs. THAT IS NOT CHANGING…. Waiting for that to sink in. Roger?

    Additive means that some customers, and the number is increasing relative to the total, were asking for something new: “take the complexity of interop and integration out for our homogenous x86 infrastructure”. That’s what the VCE go to market, and Vblocks are all about. Increasingly customers are starting to tell us they look at the entire stack underneath VMware (virtualization generally, but VMware is so far out ahead, that I’m going to use it explicitly here) as “integrated system”. Some of them were building their own “integrated infrastructure stacks”, others were looking at their vendors to support them in this. This idea is analagous to how servers can be viewed as components (HBAs, chipsets, memory, CPU, disks) OEMed to a server vendor (aka HP, Dell, Cisco, etc.), but today, the customer views them as a SYSTEM. You buy it from one place. That one place supports you. That one place integrates those elements. Those elements are available via a single SKU. THAT’S the request we’re getting from that set of customers.

    Remember – NOT SUBSTITUTIVE, BUT ADDITIVE. The proof is obvious, you can see EMC continuing to partner with Microsoft. Cisco continues to partner with NetApp, EMC partners with Brocade, VMware continues to partner with everyone.

    That’s not confusing. Those partnerships represent our traditional go-to-market model. The VCE partnership represents the new integrated infrastructure go to market model.

    2) I never said that alternatives to UIM would never be as good because the 3 parties somehow “keep something secret” (again the conspiracy theory – would you please stop it, and stop misrepresenting what I say). All the APIs presented by the 3 parties are shared openly, with no preference. UIM could be created by any 3rd party. What I DID say is that one of UIMs strengths if you have a Vblock is that since it doesn’t support anything outside a Vblock is that we can iterate faster, since there is less variation. THAT IS ALSO A WEAKNESS (since it only has value if it’s a Vblock) – but of course, that’s a customer choice – do they want to go that way, yes or no.

    3) On the call specifically, you asked if UIMv2 would support other server platforms. My comment was that right now NO, that there’s discussion about it, but our current thinking is that if people want to “mix and match”, they are asking for the traditional model, and that there are MANY excellent “manager of managers” (BMC, NewScale, Scalent, etc). I did say that I’ve never found anyone who LOVES those tools (and even used heterogenous EMC control center as an example). The reason tends to be: a) they require some integration to make work, and that’s an ongoing effort as things in the stack change – an erector set, so to speak; b) since their value intrinsically is that they can “orchestrate anything”, they tend to bring things all down to the “lowest common denominator”.

    4) The question was asked on the call (again, please listen readers) about the Ionix assets which were bought by VMware. My answer was black and white, and again, not represented here. All the assets transferred were at the physical infrastructure layer and UP (guest/host provisioning/compliance in SCM, service desk management, etc). People increasingly were looking to VMware for that, not EMC. The assets focused on the physical infrastructure layer and DOWN stayed at EMC. UIM is a clear example of the latter.

    I also pointed out on the call that VMware will continue to work down the path (which each vendor will chose to support to varying degrees) of orchestrating all physical infrastructure – look at VAAI v1 as an early example of that in the storage domain as an example. These will be, by definition EMC will of course fully support that.

    Is that more clear? Anyone doubting the text above, please listen to podcast.

    Please keep the “spin” to a minimum, shall we?

  • http://chucksblog.emc.com Chuck Hollis

    Hi Chris

    I have to say, I’m having a very difficult time following your logic here.

    I think you’re claiming that (a) because EMC is offering an integrated stack of products with its partners that (b) EMC will not support other alternatives and (c) the resulting stack is seen by you as a “lock in”.

    I’ll give you credit for being controversial, but no points for correctness.

    None of what I’m about to say will be appreciated by you if your goal was to simply drive traffic by making outrageous claims. But if you’re sincerely interested, please read on …

    A major cost of stack-building is writing interfaces, testing and documenting the results. Most of this cost falls on the upper layer management tools. If a vendor limits the number and type of entities that need to be managed, a much better management interface can be produced. It’s simple economics.

    Doing this sort of stack integration does not impact the “open-ness” of the components in the least. The underlying APIs and interfaces are still available to anyone who wants to use them.

    Nor is the integrating tool any less “open” because its now used to provide an integrated management experience. The interfaces in Ionix (and UIM) are still the same and available to all.

    Put differently, the act of creating an integrated management experience does not make the participating technology any less “open”. Customers have no fewer choices than before, and they now have new ones to consider.

    The primary advantage of something like a Vblock is time-to-value: it’s pre-integrated. Sure, an army of smart technologists could probably build something similar given enough time and money, but that’s expensive.

    There is no component of a Vblock that can’t be purchased and used independently of any other component.

    You are more than welcome to your opinions on pre-integrated infrastructure vs. more traditional build-your-own approaches: to each his own.

    However, claiming that (a) Vblocks are not open and create lock-in and (b) EMC does not plan to support non-Vblock customers is simply outrageous.

    If your goal was to create unfounded controversy, you’ve succeeded. If your goal was to have an intelligent and somewhat fact-oriented conversation, I think you’ve missed the boat here …

    — Chuck

  • http://breathingdata.com Ed Saipetch

    Disclaimer: I work for EMC.

    I think Greg hit the nail on the head. We’ve tried to do multi-vendor management and orchestration but in my opinion we don’t bring the complete picture together. There is always something missing or not smooth enough or too slow to support newer components.

    This is the same reason I’ve been beating the API bandwagon. The funny thing is that when I say that I get two different reactions. From the “old school” enterprise guys, I get “Oh you mean standards?” and from the newer “web 2.0” types, I get oh you mean soap/REST etc. I believe you can maintain some type of standardization but not be bogged down for years trying to get parties to agree while still giving open APIs and agility.

    UIM is headed down this path by exposing those APIs while also giving the best support for the Vblock platform it can. It can’t do this if it’s trying to be everything to everybody. It’s not lock-in, it’s “we’re doing our best”.

  • admin


    Actually you are right, I did misquote you – and this is the only reference to you I made – all the other comments on this post were my thoughts, not your comments. You actually said if customers want to go their own way and manage the components separately, “God Bless Them”. This is 37 minutes into the podcast. The remainder of my post does not refer to you – it is my opinion – I am happy to make this clear.

    VAAI in itself isn’t software that supports orchestration. It is merely an API for offloading computing resources to the underlying hardware in order to support more intensive functionality (i.e. vmotion/storage vmotion).

    I agree, let everyone listen to the podcast and make their own minds up.

    One last thought. I don’t believe my position is always made by being argumentative or negative and it’s rather a gross generalisation to make. However if there are gotchas with implementing certain technology, then they should be called out and discussed. I’m not saying here that UIM is a bad thing – what I’m saying is it may tend customers towards lockin they don’t want to have.


  • admin


    Thanks for the comments. I think it is worth touching on the subject of integrated and non-integrated stacks. As an architect, I have to consider the issues/risks involved in either taking all components from a single vendor, or retaining flexibility of choice. You’re entirely right; integrating the separate components may be more expensive, after all as a customer you’d be paying for the full software development, rather than acquiring a licence for a tool that a vendor such as EMC has charged a price for in terms of a wider deployment.

    However if I choose the integrated route and associated software, what’s my exit route if I decide any or all of those components are not acceptable at some time in the future? At the moment with Vblock and UIM, I’d have no exit strategy other than to stop using UIM and find another orchestration process. For those companies prepared to accept that scenario, that’s fine; for those who don’t then they should be aware of the implications.

    I can’t honestly believe you think all vendors are totally open with all of their APIs, specifications and interfaces. If they were (in the storage industry), then SNIA SMI-S would have been a raging success, instead of the generic implementation we see today. There are agreed (and sometimes negotiated) APIs and those which aren’t published. This isn’t a dig at EMC – it’s a general statement.

    The move towards private and public cloud represents a bigger risk for organisations. It requires going “all in” on every piece of technology (server/storage/network/platform) rather than being able to retain flexibility. Surely in that scenario, customers deserve to understand the risks?

    Oh, one last thought. I don’t need or choose to write EMC articles for the traffic; I’m sure I could pick plenty of other subjects/companies for that (just look what happens when I mention Netapp for example). 🙂


  • http://chucksblog.emc.com Chuck Hollis

    Hi Chris

    I think your reply to my comment was much more logical and reasoned than the post itself.

    Your key point is well taken: changing the underlying infrastructure will likely impact how the infrastructure is managed and orchestrated. We isolate and abstract as much as possible, but it’s not perfect.

    Change the hypervisor from, say, VMware to Hyper-V and it’ll likely be different. Move from, say, an Intel-based approach to an AIX approach, and it’ll be different.

    That’s not only true for UIM, it’s also true for just about every management layer that’s out there — whether purchased or home grown.

    So I guess I’m missing your point.

    Sooner or later, every IT organization has to make choices, and get on with it. Vblocks and everything else represent another interesting choice that take nothing else away from customer flexibility.

    You do have to admit — your choice of sensationalist title “Will EMC Leave non-Vblock Customers Out In The Cold” is rather inconsistent with your desired self-portrayal as an industry expert and consultant.

    You know as well as I do that EMC isn’t going to leave our customers out in the cold. We haven’t done that in the past, and we’re not going to do it in the future.

    So, what’s up with the tabloid journo approach?

    — Chuck

  • http://breathingdata.com Ed Saipetch

    Disclaimer: I work for EMC.

    I think in general we try to make those statements about being open and doing our best. At the end of the day though, motives will always be in question so I can say we can only show we’re open (vs. lock-in) by our behavior. I’ve gone on record in public saying that we need to do a better job of giving access to *useful* APIs and methods. My statement can rightfully be viewed as selfish because, it’s better for myself and EMC if more people adopt our technology. The flip side is that I/we love to help solve people’s challenges.

    The reason why the primary message for UIM out in the field isn’t about “we provide open APIs” is because so many customers just want the first main value prop which is “We let you orchestrate your IT infrastructure in a stack. We allow you to treat your storage, compute and networking as pools. We enable you do deliver these resources as service offerings.”

    Right now customers are conflicted. They want maximum choice but also quickest time to market. To really innovate, a lot of companies are realizing that you have to simplify and do it well instead of giving people unlimited choices. This is evident in the vblock configurations. The best part about all of this is that we provide them with either.

    I know you and I have talked at length before and I don’t want this to sound like a commercial, it’s a strong opinion of mine.

  • IT Guy

    Why nothing solid for Microsoft hyper-v seems like pretty much the same concepts as VMware to me especially, when you lay on the sale pitches aside, curious why any vendor would want to take a proprietary stance and close the door on a segment of their revenue. People like freedom and compatibility and the real people making things happen could care less about spitting a vendor just because the their big.

  • IT Guy

    Why nothing solid for Microsoft Hyper-v seems like pretty much the same concepts as VMware to me especially, when you lay the sale pitches aside. Curious why any vendor would want to take a proprietary stance and close the door on a segment of their revenue. People like freedom and compatibility and the real people making things happen could care less about spitting a vendor just because the vendor might be big.

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×