What Customers Want from EMC and VMware

There has been so much speculation about EMC/VMware lately and I continue to be surprised by how much the speculation feeds itself. One reporter speculates, and then another reports the first as a source. It’s all like a snake eating its own tail.

My perspective is based on the customers I talk to and mirrors the one Joe Tucci staked out in response to the analysts on EMC’s most recent earnings callthe customers I talk to want the Federation of EMC/VMware/Pivotal/RSA to be MORE integrated, while fiercely resisting models where things are too coupled.

It’s funny because those sound like polar opposites, but I also get where they are coming from. Customers want a loose coupling that gives freedom of choice to pick a part or pick the whole.

People jokingly compare our Federation to another Federation. The analogy to the fictional Star Trek Federation is apt beyond the common name. That other Federation is a collection of different planets and cultures. They have different strengths and weaknesses, but come together on common goals. That’s pretty familiar territory for the employees of EMC, VMware, Pivotal and RSA.

What do I hear from customers about what they want – specifically?

  • They want to be able to use everything in the VMware portfolio without being obligated to using EMC or Pivotal.
  • They want to be able to use EMC without necessarily using VMware.
  • They want to be able to use Pivotal Cloud Foundry and the Pivotal Big Data Suite anywhere, including vCloud Air and on their VMware-powered on-premises clouds (the most common deployment model for Pivotal Cloud Foundry), but also on AWS, Azure, and others.
  • Many Isilon customers are very happy to see EMC partner with Cloudera. Heck, EMC even resells Cloudera for people who want to bundle these together (El Reg covers that here). Want a pure open source Apache Hadoop distribution instead to align yourself with the Open Data Platform (ODP)? EMC partners with Hortonworks (see that here). A pretty clear example of choice.
  • What about the new world of Cloud Native Applications and how to best support them at the infrastructure level?
    • Some customers passionately believe in a vision of Cloud Native apps that runs on a pragmatic view. This view is that perhaps it’s best to build new apps on the same unified cloud stack which runs kernel mode VMs and containers simultaneously, can present via the vRealize/vCloud APIs and equally via the Openstack APIs, and offers rich virtual infrastructure services when needed, and not when not. This is the Federation Enterprise Hybrid Cloud, which industrializes the VMware stack with rich workflows and integration with a broad ecosystem. The people and process of this “unified cloud” approach often struggle with SLAs, ITIL processes geared to the most legacy app whilst also operating with the agility that the new cloud native apps desire (and demanding none of the infrastructure resilience). This is not a technical issue, but a very real one nonetheless.
    • Other customers are equally passionate in a diametrically ooposed direction – that while you CAN run Cloud Native Applications on infrastructure and operational models designed for classic infrastructure-dependent applications, you SHOULDN’T. Instead, you bias for elasticity, programmability, cloud-level scale and economic models. Beyond the technology, this operational model fits the DevOps cultural model. This cloud usually runs adjacent to a “unified cloud” that powers the traditional applications. Does the Federation have an answer?  You bet! This is the Pivotal Cloud Foundry + VMware Photon Platform + EMC VxRack solution which was discussed at VMWorld 2015.
    • Other customers reject VMware’s role in the world of Cloud Native Apps with passion. I think that’s a little foolhardy – because outside some of the SaaS startups I meet with, few customers would see a ton of benefit from building their own Cloud Native unstructured PaaS (DIY PaaS that starts with building on top of Mesos + Marathon/Kubernetes) built on homebrew IaaS models. Outside SaaS startups (which rock with this approach), many enterprise customers go down that path and come back 18 months later saying “help!” VMware can make the Photon Platform the “Enterprise IaaS for pure Cloud Native Apps.” That said – those customers commonly believe in a purist open source model, and bias towards the efforts that Pivotal and EMC are pursuing with Project Caspian as the “industrialization” of a purist open source stack. This is another manifestation of choice.

These same customers also tell me that as soon as their partners turn into “pick my stack, my full stack – like it or not,” they move from being a partner to being a vendor. When they push that envelope too far, such as cranking licensing/pricing in a negative direction (Oracle is constantly the reference example) – they move from passive dislike into frustration, anger and then full on rage.

This is a delicate balancing act.   Everyone out there is trying to make it easier for companies to source more from them, but as soon as the choice is not driven by the customer… well, those customers end up feeling like I feel about my cable company: “Their internet rocks. Their set top and cable programming sucks. Their mobile phone sucks. I DON’T WANT BUNDLING.”

I also hear another thing more and more often – customers that dig EMC, also dig VMware and Pivotal. They want us to work more closely together. There are customers every day that are going all in on the Federation, and see benefit to their business. And, if you listened to the recent analyst call (transcript here) you heard Joe saying how those customers spend on average 2x more with EMC and VMware and move faster with Pivotal. 

I want to humanize this for a second.   My daughter was in the ER three weekends back (fear not – nothing serious – just a wakeboarding head injury with no permanent damage other than a wound to her pride). During those long hours, EMC, VMware, Pivotal, RSA and the Federation were the last thing on my mind.   Afterwards I realized the hospital had a new PACS system – and that in all likelihood we power that system – so in a way we as the Federation had a part to play (a VERY small part relative to the doctors!)

Every day families work through healthcare issues that make my weekend detour look easy. These things matter – and are about making people’s lives better – not just driving technology forward.

Want another example of making lives better?  EMC’s sustainability report is a fascinating read.

What’s interesting about these “making the world better” and “getting to an outcome” stories? They don’t start with low-level technology elements. This is difficult to internalize as a technologist who likes “being in the weeds.” Technology matters – in fact it’s central – but the real magic is in “putting it all together.”

This is the other macro thing that is driving the “Federation Better Together” for me and may perhaps suggest that the balance point in the balancing act may be moving.

Every day I talk to customers, more are saying: I’m done wasting my time on lower-level integration – I want a faster outcome.  I know that part of moving faster is focusing less on “lock in” that is no longer material, and more on picking partners that I trust and redirecting efforts higher up the stack – period.

A good friend and former colleague (good luck in the new gig Tyler!) did an absolutely BRILLIANT post on “lock-in” here I would highly recommend. His definition is perhaps the best I’ve ever seen: How much friction (and what would it cost to overcome) am I introducing to our environment, and is the value we’re gaining worth it?   

Through that lens, bad “lock in” is a situation where the friction to move outweighs the benefits of moving and good “lock in” is a situation where the friction to move is dwarfed by the benefits of moving.

What people are coming to realize is that lock-in at lower levels of the stack is now at a point where the friction to move is low. This is due to open APIs and open source coupled with much better abstraction through virtualization and containerization. Even moving from one IaaS stack to another is possible (that has more friction though). The new “high friction” comes from data gravity (this remains really hard to move – and steers compute to tend to want to co-locate), governance/compliance/regulation, and hard-coding your app to someone’s API without some open protection (the most dangerous of the these elements).

The ultimate proof point (in the lock-in vs. agility debate) is the rapid growth of the public cloud stacks – where you have ZERO control over the stack (or the services).

This is all to say the following:

  1. When customers want faster outcomes (which is happening more and more)…

AND

  1. They realize that lock-in is a ratio of “friction to move:benefit of moving,” not a monster to be feared…

THEN

  1. They ask the Federation to come with answers to the questions of ‘what if we were all in with you?’ and ‘does the ratio of friction:benefit work in my favor?’

This is the story of so many customers I see around the globe.

There is so much to do and we can clearly get better!

This question, “what can we do to make the Federation work better, while striving to not remove the strength that comes from preserving the cultures, autonomy, and freedom of motion?”, has been keeping me very busy over the years – and no time more than over the last couple of months.

I believe there are six buckets to what we can do to make the Federation work even better (IMHO):

  1. Services – a common team approach to delivering on integrated Federation projects; operating based on the best skills to deliver, regardless of Federation team member (we’ve largely cracked this one).
  2. Sales – to be applied when a customer says “I want a Federation team where the buck stops – and leverages the whole Federation portfolio for what they think is right.” This means being able to do Federation ELAs, and other operational considerations.  We’ve started to apply Federation account coverage for customers who really want to go “all in” with us – early days to be sure, but exciting!
  3. Software Defined Storage – together, the SDS portfolio of VMware and EMC is second to none – from extending traditional external storage (VVols/ViPR) and in other cases replacing external transactional storage with SDS (VSAN and ScaleIO). Together we cover vSphere only-use cases, and also any heterogenous use case. Together we offer SDS data planes beyond transactional storage with Elastic Cloud Storage (ECS). Together as VMware and EMC there is no peer in the ecosystem when it comes to a complete, and open SDS portfolio.
  4. Converged Infrastructure – a big part of moving faster is abandoning mix-and-match at the lowest levels of the stack. This is causing vendor ecosystems to collapse and things that were obvious in the past simply don’t work anymore. Maybe CI isn’t an ecosystem play anymore? SDS with validated hardware still seems to work as an ecosystem thing (think of VSAN-ready nodes, or the new ScaleIO nodes). vSphere certainly is a massive ecosystem play (massive ecosystem). But when it comes to real CI (not assembled reference architectures), customers are drawing clear lines about stacks that they like and they don’t like – technologically, as well as strategically and through the support lens. New battle lines are being drawn. This is a function of something more fundamental: the new commodity is the full IaaS stack. It’s not to say that all IaaS stacks are the same, rather that IaaS is now the level of infrastructure comparison.
  5. Cloud – the consumption model of technology that cloud creates needs to operate at the Federation level.  Not that we don’t continue to partner openly with SPs and Telcos, but there needs to be a more Federation-level model for it.
  6. A clear strategic position on the infrastructure design point built for Cloud Native Applications workloads. This area (Cloud Native Application and the IaaS that underpins it) is one of the biggest hairballs because right now it seems that depending on the customer, the “pragmatist” and “purist” views each have a place because the landscape is moving fast! More work needed here – but you can see we’re all over it.

In the end (and most importantly!), I want to say a huge “thank you” to our Federation customers. Know that we’re working furiously on 1-6, while maintaining our promise to you of always offering choice and embracing an open ecosystem.

About the Author: Chad Sakac

Chad Sakac leads the Pivotal Container Service (PKS) efforts at Pivotal where he brings together the Engineering, Marketing and GTM aspects of the business – with the goal of building the best Enterprise Container Platform together with VMware – part of how Pivotal is transforming the way how software and the future is built. PKS is a joint effort with VMware – and the effort involves bringing the immense resources of two great companies together. This alliance part of Chad’s role extends to all of the elements of how Pivotal works with Dell Technologies (Dell, Dell EMC, VMware, RSA, Secureworks, Virtustream, Boomi) - across the transformational methodologies (Pivotal Labs, Platform Acceleration Labs, Application Transformation and more) and technologies (all of Pivotal Cloud Foundry, Pivotal Data) of Pivotal as a whole. Prior to this role, Chad spent 14 years at Dell EMC where he was responsible for several technical customer focusing on customer and partner innovation – most recently as the President and GM of the Converged Platform and Solutions Division (CPSD), and prior to that leading all global Systems Engineering team. Before joining EMC, Chad led the Systems Engineering team at Allocity, Inc. Chad authors one of the top 20 cloud, virtualization and infrastructure blogs, “Virtual Geek” He holds an Electrical Engineering degree from the University of Western Ontario, Canada.