Last week, Forbes and ZDnet posted articles discussing the cost of various cloud (451 source material behind wall) full of dollar per hour costs analysis. Their analysis talks about private infrastructure being an order of magnitude cheaper (yes, cheaper) to own than public cloud; however, the open source price advantages offered by OpenStack are swallowed by added cost of finding skilled operators and its lack of maturity.
At the end of the day, operational concerns are the differential factor.
The Magic 8 Cube
These articles get tied down into trying to normalize clouds to $/vm/hour analysis and buried the lead that the operational decisions about what contributes to cloud operational costs. I explored this a while back in my “magic 8 cube” series about six added management variations between public and private clouds.
In most cases, operations decisions is not just about cost – they factor in flexibility, stability and organizational readiness. From that perspective, the additional costs of public clouds and well-known stacks (VMware) are easily justified for smaller operations. Using alternatives means paying higher salaries and finding talent that requires larger scale to justify.
Operational complexity is a material cost that strongly detracts from new platforms (yes, OpenStack – we need to address this!)
Unfortunately, it’s hard for people building platforms to perceive the complexity experienced by people outside their community. We need to make sure that stability and operability are top line features because complexity adds a very real cost because it comes directly back to cost of operation.
In my thinking, the winners will be solutions that reduce BOTH cost and complexity. I’ve talked about that in the past and see the trend accelerating as more and more companies invest in ops automation.
This is the first part of 3 posts that look into the real future for “private clouds.”
This concept is something that was initially developed with Greg Althaus, my colleague at Dell and then further refined in discussions with by our broader team. It grew from my frustration with the widely referenced predictions by the Gartner Group of a private cloud explosion. Their prognostication did not ring true to me because the economics of “public cloud” are so compelling that going private seems to be like fighting your way out of a black hole.
We’ll get to the gravity well (post 3 of 3) in due time. For now, we need to look into the all knowing magic 8 cube.
Our breakthrough was seeing cloud hosting as a 3 dimensional problem. We realized that we could cover all the practical cloud scenarios with these 8 cases. Showing in the picture (right).
Here are the axis:
X: Hosted vs. On-site – where are the servers running? On-site means that they are running at your facility or in a co-lo cage that is basically an extended extraterritorial boundary of your company.
Y: Shared vs. Dedicated – are other people mixing with your solution? Shared means that your bytes are secretly nuzzling up to someone else’s bytes because you’re using a multi-tenant infrastructure.
Z: Managed vs. Unmanaged – do you’re Ops people (if you have any) able to access the infrastructure that runs your applications? Unmanaged means that you’re responsible for keeping the system operating.
With 3 axis, we have a 8 point cube.
MSH – a PaaS offering in which every aspect of your application is managed and controlled. GAE or Heroku.
MSO – remember when people used to buy a mainframe and them lease off-hours extra cycles back to kids like Bill Gates? That’s pretty much what this model means.
MDH – a “mini-cloud” run by a cloud provider by dedicated to just one customer. Dr. Evil thinks this costs one milllllllllion dollars.
MDO – a cloud appliance. You install the hardware but someone else does all the management for you.
USH – IaaS. I think that Amazon EC2 is providing USH. It may be a service, but you’ve got to do a lot of Ops work to make your application successful.
USO – OpenStack or other open source cloud DYI frameworks let a hosting provider create a shared, hosted model if they have the Ops chops to run it.
In thinking this over, we realized that cloud customers were not likely to jump randomly around this cube. If they were using MSH then they may want to consider MDH or MSO. It seemed unlikely that they would go directly from MSH to UDO as Mr. Bittman suggests; however, the market is clearly willing to move directly from UDO to MSH.
We had a good old-fashioned mystery on our hands… the answer will have to wait until my next post.