Props are due to Dave McCrory for his fine investigative work reading the VMware cloudy tea leaves. Over the weekend, he posted a series of articles about VMware’s Open PaaS and VMforce offerings. This is a significant write-up based on information gleaned from their public code check-ins that he validated with them after the fact.
I have not had time to digest it yet – check back later for actual commentary.
Between partnering meetings, I bounced through biz and tech sessions during Day 2 of the OpenStack conference (day 1 notes). After my impression summary, I’m including some succinct impressions, pictures, and copies of presentations by my Dell team-mates Greg Althaus & Brent Douglas.
Greg PresentingBig Crowd on Day 1
Yesterday, Dell sent me to be part of our OpenStack vanguard for the design summit. The conference is fascinating and productive for the content of the sessions and even more interesting for the hallway meetings.
It’s obvious looking at the board composition that RackSpace and NASA Nova are driving most of the development; however, the is palpable community interest and enthusiasm. Participants and contributors showed up in force at this event.
RackSpace and NASA leadership provides critical momentum for the community. Code is the smallest part of their contribution, their commitment to run the code at scale in production is the magic rocket fuel powering OpenStack. I’ve had many conversations with partners and prospects planning to follow RackSpace into production with a 3-6 month lag.
Beyond that primary conference arc, my impressions:
Executive Tweet: #openstack: Partners & Code = great progress. Networking = needs more love
Other notes:
My personal bias against SANs in cloud architectures is well documented; however, I am in the minority at my employer (Dell) and few enterprise IT shops share my view. In his recent post about CAP theorem, Dave McCrory has persuaded me to look beyond their failure to bask in my flawless reasoning. Apparently, this crazy CAP thing explains why some people loves SANs (enterprise) and others don’t (clouds).
The deal with CAP is that you can only have two of Consistency, Availability, or Partitioning Tolerance. Since everyone wants Availablity, the choice is really between Consitency or Partitioning. Seeking Availability you’ve got two approaches:
According to CAP, Legacy and cloud approaches are so fundamentally different that they create a “CAP Chasm” in which the very infrastructure fabric needed to deploy these applications is different.
As a cloud geek, I consider the inherent cost and scale limitations of a CA approach much too limited. My first hand experience is that our customers and partners share my view: they have embraced AP patterns. These patterns make more efficient use of resources, dictate simpler infrastructure layout, scale like hormone-crazed rabbits at a carrot farm, and can be deployed on less expensive commodity hardware.
As a CAP theorem enlightened IT professional, I can finally accept that there are other intellectually valid infrastructure models.
See Mom? I can play nicely with others after all.
Having the requirement benefit of working with both Dave McCrory and Joyent on a daily basis at Dell, I cannot resist weighing in on the blog pong between them.
Dave’s post comparing VM pricing prompted Joyent to blog that VMs are not the only measure of cloud.
While I completely agree that clouds are not all about VMs, I think that Joyent is too limited in their definition of cloud in their reply. We’re seeing an emergence of services as the differentiator between clouds.
Looking at Amazon, Azure, and Google, the clear way to reduce cloud spend is to migrate applications to consume their services (SQL, Storage, Bus, etc).
If cloud users are primarily concerned about price per hour (which I’m not convinced is the case) then they have real motivation to migrate from purely VM (or SmartMachine(tm) ) based applications to ones that use services.
My current title is so buzz word heavy it means nothing. How about this?
As a senior cloud juicer at Dell, my job is to wring value for customers from cloud solutions, make rain with new opportunities, and identify thunderheads and storm fronts that will bring the winds of change.
In my opinion, one of the biggest challenges facing companies like Dell, my employer, is how to help package and deliver this thing called cloud into the market. I recently had the opportunity to watch and listen to customers try to digest the concept of
PaaS.
While not surprising, the technology professionals in the room split into across four major cultural camps: enterprise vs. start-up and dev vs. ops. Because I have a passing infatuation with pastel cloud shaped quadrant graphs, I was able to analyze the camps for some interesting insights.
The camps are:
This graph is deceiving because it underplays the psychological break caused by willingness to take risks. This break creates a cloud culture chasm. 
On one side, the reliable Imperialists want will mount a Royal Navy flotilla to protect the Crown Jewels in a massive show of strength. They are concerned about the security and reliability of cloud technologies.
On the other side, the MacGyvers are working against a ticking time bomb to build a stealth helicopter from Legos they recovered from Happy Meals™. They are concerned about getting out of their current jam to compile another day.
Normally Imperialists simply ignore the MacGyvers or run down the slow ones like yesterday’s flotsam. The cloud is changing that dynamic because it’s proving to be a dramatic force multiplier in several ways:
The bottom line is that the cloud is allowing the MacGyvers to be faster, stronger, and more innovative than ever before. And we can expect them to be spending even less time polishing the brass in the back office because current SaaS companies are working hard to help make them faster and more innovative.
For example, Facebook is highly incented for 3rd party applications to be innovative and popular not only because they get a part of the take, but because it increases the market strength of their own SaaS application.
So the opportunity for Imperialists is to find a way for employee and empower the MacGyvers. This is not just a matter of buying a box of Legos: the strategy requires tolerating enabling embracing a culture of revenue focused innovation that eliminates process drag. My vision does not suggest a full replacement because the Imperialists are process specialists. The goal is to incubate and encapsulate cloud technologies and cultures.
So our challenge is more than picking up cloud technologies, it’s understanding the cloud communities and cultures that we are enabling.
What? No umbrella drinks! What type of meeting is this anyway?
This post is the final post laying out a rethinking of how we view user and buyer motivations for public and private clouds.
In part 1, I laid out the “magic cube” that showed a more discrete technological breakdown of cloud deployments (see that for the MSH, MDH, MDO, UDO key). In part 2, I piled higher and deeper business vectors onto the cube showing that the cost value of the vertices was not linear. The costs were so unequal that they pulled our nice isometric cube into a cone.
The Cloud Gravity Well
To help make sense of cloud gravity, I’m adding a qualitative measure of friction.
Friction represents the cloud consumer’s willingness to adopt the requirements of our cloud vertices. I commonly hear people say they are not willing to put sensitive data “in the cloud” or they are worried about a “lack of security.” These practical concerns create significant friction against cloud adoption; meanwhile, being able to just “throw up” servers (yuck!) and avoiding IT restrictions make it easy (low friction) to use clouds.
Historically, it was easy to plot friction vs. cost. There was a nice linear trend where providers simply lowered cost to overcome friction. This has been fueling the current cloud boom.
The magic cube analysis shows another dynamic emerging because of competing drivers from management and isolation. The dramatic saving from outsource management are inhibited by the high friction for giving up data protection, isolation, control, and performance minimums. I believe that my figure, while pretty, dramatically understates the friction gap between dedicated and shared hosting. This tension creates a non-linear trend in which substantial customer traction will follow the more expensive offerings. In fact, it may be impossible to overcome this friction with pricing pressure.
I believe this analysis shows that there’s a significant market opportunity for clouds that have dedicated resources yet are still managed and hosted by a trusted 3rd party. On the other hand, this gravity well could turn out to be a black hole money pit. Like all cloud revolutions, the timid need not apply.
Post Script: Like any marketing trend, there must be a name. These clouds are not “private” in the conventional sense and I cringe at using “hybrid” for anything anymore. If current public clouds are like hotels (or hostels) then these clouds are more like condos or managed community McMansions. I think calling them “cloud shards” is very crisp, but my marketing crystal ball says “try again.” Suggestions?
In part 1 of this series, I laid out the “magic cube” that describes 8 combinations for cloud deployment. The cube provides a finer grain understanding than “public” vs. “private” clouds because we can now clearly see that there are multiple technology axis that create “private IT” that can be differentiated.
The axis are: (detailed explanation)
Cloud Cost Model
In this section, we take off our technologist pocket protectors and pick up our finance abacus. The next level of understanding for the magic cube is to translate the technology axis into business vectors. The business vectors are:
X. Capitalization: OpEx vs. CapEx. On the surface, this determines who has ownership of resource, but the deeper issue is if the resource is an investment (capital) or consumable (operations). Unless you’re talking about a co-lo cage, hosting models will be consumable because the host is leveraging (in the financial sense) their capital into operating revenue.
Y. Commitment: PayGo vs. Fixed. Like a cell phone plan, you can pay for what you use (Pay-as-you-go) or lock-in to a fixed contract. Fixed is generally pays a premium based on volume even though the per unit cost may be lower. In my thinking, the fixed contract may include dedicated resource guarantees and additional privacy.
Z. Management: Insource vs. Outsource. Don’t over think this vector, but remember I not talking about off shoring! If you are directly paying people to manage your cloud then you’ve insourced management. If the host provides services, process or automation that reduces hiring requirements then you’re outsourcing it IT. It’s critical to realize that you can’t employee fractional people. There are fundamental cloud skillsets and tools that must be provided to operate a cloud (including, not limited to DevOps).
THE 3 VECTORS ARE NOT EQUAL!
If you were willing to do some cerebral calisthenics about these vectors then you realized that they are not equal cost weights. Let’s look at them from least to most.
The unequal cost weights pull our cube out of shape. They create a strong customer pull away from the self-managed & CapEx vertices and towards outsourced & OpEx. I think of this distortion as a cloud gravity well that pulls customers down from private into public clouds.
That’s enough for today. You’ll have to wait for the gravity well analysis in part 3.
Rob Hirschfeld 