I spent a couple of days this week at CloudBeat, an event that Paul Miller and I have, for the past three years, consulted to on content. The highlights of the show for me where the panel I moderated looking at hybrid cloud (panelists Chris Rence of Digital River, Christian Reilly from Bechtel and Matthew Lodge of VMware) and Paul Miller’s incendiary session which contained luminaries Marten Mickos from Eucalyptus and Randy Bias from Cloudscaling. For passive coverage of the two sessions see here and here.
Maybe it’s Christian Reilly rubbing off on me but after hearing Mickos and Bias go hammer and tongs over the definition and technical minutiae of what constitutes true adherence to the AWS API model I was left with a resounding desire to shout “meh” from the rooftops. And after a pleasant dinner attended by the same Mr Reilly and hearing him opine (as only he can) about the realities of enterprise IT, I was left thinking one thought above all: NO ONE CARES! Now don’t get me wrong, the punditry earns its crust assessing compelling strategies and advising vendors the “one true course” for their strategy, but frankly, if the particular issue of AWS compatibility for companies building private clouds was of complete and utter importance to customers actually building said clouds, Eucalyptus and Cloudscaling, the two companies hanging their hats on the importance of said API compatibility, would be leaving all others in their dust. That wouldn’t seem to be happening.
The only thing that matters is what enterprises actually ask for, and all the messages I get from enterprise CIOs I speak to is that the AWS compatibility debate is an entertaining little foray when they’re bored and want to laugh at their own industry but it is ultimately a sideshow to what are their real drivers for change. Simon Wardley preaches from the rooftops that OpenStack is a “dead duck” and it can only survive by (among other things) adopting the AWS API. Yet no one cares. Pat Gelsinger preaches to the partner masses that a “workload lost to AWS is a workload lost forever”. Yet the customers moving those workloads… don’t care. Members of the OpenStack community decry AWS as the devil incarnate and akin to a Frankenmonster of Hitlerite proportions. And…. you guess it… no one cares.
And no one cares because enterprises are making the decisions they need. They’re doing the new stuff on AWS and seeing it do amazing things for agility and focus. They’ve got their existing applications on VMware kit and are attracted to the promise of a new world that vHCS is promising to bring. They’re standing up private cloud built with OpenStack, with CloudStack, with MehStack (TM) and with every other stack under the sun. They have dusty old mainframes in the corner and are (gasp!) running mission critical workloads on them. In short, enterprise IT is doing what it need to do. Focusing on short, and perhaps mid term delivery of its objectives, and letting the peanut gallery go on and on and on about other stuff.
So, in case anyone takes that as a statement that there is nothing interesting going on in the industry, that’s patently not the case. A couple of cases in point.
vHCS and a Compelling (If Late) Value Prop
Moderating the session with Matthew Lodge was great fun, and I have to thank Lodge for being gracious with my somewhat snarky remarks. I mean let’s face it. VMware have, for years, been telling enterprises that all they need is a good healthy dose of virtualization on top of their own (or VMware’s channel partner’s) hardware to drive all the efficiency they need. They may not have quite said that cloud was an unnecessary and futile endeavor but they got close. In what is hard not to describe as a switch and bait they announced vHCS, a hybrid offering which, as the marketing site announces “quickly and seamlessly extends your data center into the cloud using the tools and processes you already have”.
So my first question to Lodge was: why now?
While not directly answering my question, the truth is obvious: VMware have a channel network and a sales staff that were finely tuned to one particular way of doing things – selling VMware kit at monstrous cost and enjoying big license fees for doing so. Any cloud product was always going to cause internal and channel pain – that is a given. At the same time, and doubly reinforcing their strategic decision to avoid pushing the pedal on cloud early, their customers are (at least to a reasonable extent) traditional enterprises that are both conservative in how they buy and adopt new technologies, and have some existing investments that they need to think about. So in the VMware world you have pressures from the sales channels to slow down, and no massive pull from customers to speed up – the decision is obvious.
Fast forward to today and things have, on a number of levels, changed. AWS is obviously moving strongly into an enterprise provider and gaining significant credibility from VMware’s bread and butter customers. Those same customers are starting to question their VMware reps and saying things like “sorry, I don’t buy that any more, we need more flexibility”. Those dual factors mean that the time was right to suffer a little channel pain in an effort to protect the company moving into the next phase of the industry.
It isn’t however cast in stone. Good example – the licensing models for “traditional” VMware kit and vHCS are different. VMware spins this as a case of two different services with two very different use cases. That message will suffice for a period of time until a sufficient body of those important VMware customers come back to their reps and demand to have true utility pricing across all their infrastructure – they’ll demand it of their hardware providers and they’ll demand it of software vendors like VMware. At that point VMware will reassess, change it’s position and meet the market.
Does this mean VMware is a lying, cheating evil vendor? No, it means that VMware is a commercial entity that needs to tailor how it talks, what it delivers and how it charges for those products to the appetites and the vagaries of the marketplace – at a point in time. That is a moving target and hence changes happen.
AWS in An Entirely Different Solar System to its Competitors
Most people reading this will have seen the latest Gartner Magic Quadrant which had to be resized to allow for the massive commercial lead that AWS has in the marketplace. They out-innovate, out-perform and out-customer acquire all other comers. But hell, nothing is cast in stone. Even Lydia Leong, the Gartner analyst who co-authored the Magic Quadrant advises enterprises to (duh!) LOOK AT THEIR OWN SITUATION before deciding on a vendor:
Magic Quadrant placement is NEVER a good reason to include or exclude a vendor from a short list. You need to choose the vendor that’s right for your use case, and that might be a Niche Player, or even a vendor that’s not on the MQ at all — and even though AWS has the highest overall placement, they might be completely unsuited to your use case
Yes AWS is far in front of everyone else and, yes, if you’re a cloud vendor trying to beat AWS at its own game you’re out for a hiding. But the future is hugely varied and there is space for everyone to differentiate what they do – differentiate by geography, based on service, based on vertical focus, based on flexibility, hell, differentiate based on the color of the rainbows you have printed on your marketing literature – whatever, there are opportunities out there. So AWS’ dominance is a PITA for its direct competitors but of no real consequence to enterprise customers.
I don’t want to single out AWS and VMware for analysis – next up I’ll espouse my view on the stack brothers, OpenStack and CloudStack. Those two initiatives do a fantastic job of sniping and bitching at each other while AWS continues to grow all the time. I might even compare and contrast the four horsemen of the coming cloud apocalypse, AWS, VMware, Azure and Google. Or I might just get some crayons and draw pictures of unicorns and rainbows.
PS – Photo credit to Misha Nikulin who obviously has way too much time on his hands