Cloud Service Providers and the Dual Stack Dilemma
I wrote this blog and then jumped on Twitter to summarize/crystallize what I thought were the most important bits:
Finishing up a blog “Cloud Service Providers and the Dual Stack Dilemma” < Not sure it’s going to be a surprise to anyone…
— [Christofer] Hoff (@Beaker) September 20, 2012
Here’s the punchline: CSPs that started with VMW are in parallel deploying cloud offers on alternative stacks. Cost being only ONE reason.
— [Christofer] Hoff (@Beaker) September 20, 2012
…& w/hypervisor modularity, the capability for them to now do so without as much of a large dev./support burden means better ARPU, less risk
— [Christofer] Hoff (@Beaker) September 20, 2012
…and thus realized I didn’t really need to finish drafting the blog since I’d managed to say it in three tweets.
Twitter has indeed killed the WordPress star…
More detailed version below. Not finished. TL;DR
/Hoff
—– (below unedited for tense, grammar, logical thought or completeness…) —–
In my worldly travels over the last four years or so as Cloud has emerged as a force to be reckoned with (i.e. a segment where money can be made,) the good majority of large service providers (wireline, hosting, etc.) have almost all started to engage in the same behavior based upon their target markets.
Specifically, those service providers have pivoted to become cloud service providers (CSPs.) Those CSPs who built a business catering to enterprises or governments — those that are highly regulated, compliance and security-oriented entities — invested early in VMware.
They did this because it was, prior to the notion of “hybrid” models, the most reasonable option imagined to capture or offload on-premise enterprise IT assets and “move” them to “cloud” since the platforms were identical. Even as enterprises engaged in building private clouds, the bet was made that like platform deployments would ease the move as operational costs could be defrayed in a “hosted” capacity.
The management, orchestration, provisioning and security/compliance looked and generally behaved the same if one were running vSphere on premises as it did when the vendor used the same solutions (including solutions like vBlock which made even the underlying infrastructure identical to many enterprises.)
And all was good. For a while. And then the costs piled up. And the revenue didn’t. At least not at a pace or with margin levels that many expected.
And the business model and rigorous productization, integration, validation, and certification processes of SPs did not mesh with VMware very well — consistency, stability, quality and timeliness of deliverables matter much to service providers who in turn have to back up SLAs to their customers with their platforms.
That’s not at all to say that VMware had a bad product or that some success was not enjoyed by the CSPs. However, statistics that claim thousands of VMware vCloud “CSPs” should be taken with a grain of vSalt…
So in parallel, these same CSPs were glancing jealously at other potential cloud solutions whose cost structures were much more in line (often times “free”) with trying to maximize ARPU. But as we all know, sometimes you get what you pay for. VMware’s platforms are compelling, but to a point.
Many of these other offers were much like erector sets requiring investment and expertise that these CSPs did not have and areas of technical depth that required a new level of knowledge beyond network virtualization. Even hosting providers who may have long delivered “virtualized” services were confronted with whether to abandon (or parallelize) existing strategies for hosting and colocation and move to a multi-tenant “cloud” enabled model.
The tradeoffs in enterprise-level feature sets balanced against cost meant that the CSP economic burdens were shifted from basic integration of COTS components to full-fledged internal development and support, which didn’t necessarily mean that the solutions were cheaper after all.
Then an interesting series of events happened as AWS continued to innovate and lower prices and open source/community-based offerings such as OpenStack took flight; the ability to deliver lower cost but high-quality cloud services became more realistic. And large pools of vendors began to participate.
That said, many of the enterprise-level security and compliance knobs and buttons aren’t available generically in these offers and options like security introspection APIs are not standard fare on most of the platforms. This means that enterprises who have high compliance requirements may not be willing or able to use these platforms, but this, too, is starting to change. What CSPs are interested in now is maturing their business, controlling their own fate, costs and roadmap features…while optimizing their spend, R&D and marketing around very streamlined service offerings and market segments.
There are companies such as Piston Cloud and Nebula that offer commercialized versions of OSS stacks that have built in more security capabilities and support for audit/compliance into these stacks…and CSPs like AWS are maturing and realizing that security, monitoring, and compliance are important as they build more capability into their solutions.
Many of these CSPs have instantiated dual cloud stacks. Originally VMware (vSphere or vCloud Director) for their “enterprise” customers and then additionally one of the *stack offers for their “non-enterprise” customers…or those that seek low cost as a driving function. But the logic behind dual stacks is changing…
What’s starting to happen is that the feature sets between these offers can be viewed as starting to converge…and as they do the cost pressures on VMware have mounted as these alternatives are not only explored, but deployed. This is evident. This is why we see bundling of features at lower prices and the removal of the vTax from VMware. Let’s not forget VMware standing up their own vCloud service offering, frustrated by what is their expectation for CSP adoption not meeting the grade.
With modularity in hypervisor choices in stacks such as OpenStack, massive momentum around APIs and continued disruptive innovation in compute, networking and storage, how long will it be until the dual stack dilemma no longer is a dilemma? I know several large CSPs who are already building out their “next generation” cloud platforms. You may be surprised (or not) at their choice of technologies and supporting components.
It’s not to say that all these options are baked and ready to go (they’re not,) but when you’re about to dump millions into a cloud platform, this is a game of inches that people bet big on…and sometimes weighing the risks means hedging. Just like with what started originally with VMware.
To give you a funny example, one CSPs internal codename for their dual-stack cloud platform approach was Gemini. The next gen?
Cyclops.
😉
Hoff,
Lot’s of points above, but I found the throughts to be somewhat wondering. Maybe I am just not in tune with this specific thought process.
As all things IT related, it is the race to the bottom. IT’s primary purpose is to drive efficiency and expidite operations. It all roll’s downhill. This paradigm is what drive the “next big thing”. So, as you accurately identify above, SPs are now seeking to maximize revenue by investing in the lowest cost solution that meets service requirements.
VMware recognizes this shift and attempted to draw more value out of its core vSphere solution with the vTax. However, due to the leveling of hypervisors, the consumer revolted and took one of the following steps – ceased deployment awaiting change, migrated to another vendor, or upgraded due to technology needs. This was evident at VMworld with the lack of response to the anouncement. The consumer had already stated the vTax should go and was expecting VMware to align. Think, removal of a thorn, not a delivery of great news.
Also, now that CSPs have gone through the initial learning curve, the requirements for service delivery are much better defined. The superfluous will be pruned and core service delivery at the most cost effective and efficient means are targeted.
I believe the tiering of cloud services will not be performance bound, but service bound. The hardware will auto-tier while the serive scope itself will be defined by the the capacities and capabilities of a tier.