This is one of those questions with which I am getting bored.  You can’t attend a conference these days without someone asking that question.  The constant theorizing is akin to the classic debate of “Kirk or Picard?”  It’s a question that may never get answered, and in fact will engage the nerds for decades to come.

After my conversations last night at the Structure VIP reception, I came to the conclusion that the word “cloud” is like catnip for nerds.  You can attach the word cloud to anything to attain relevancy.

During his panel at the Structure 09 conference (being live streamed from GigaOm), James Lindenbaum from Heroku said that he doesn’t want to think about the question anymore; in fact, he wants to avoid the word “cloud” all together.  Instead, he would prefer that people focus on building applications and rely on abstractions provided by the development frameworks than to think about to cloud or not to cloud.

This just in, local San Francisco entrepreneurs are launching the world’s first cloud gas station.  They supply a true multi-tenant, pay by the drink model, removing the need to purchase your own refineries, and abstracting the gas production process to deliver a truly seamless experience for downstream customers.

Next up on the zeitgeist watch?  Attaching the word “scale” to the name of your company.

Summary

There was a report released April 15^th by McKinsey called “Clearing the Air on Cloud Computing.”  The premise of the report was that the cloud was actually quite a bit more expensive for large corporations than running their own datacenters.  While it allows a nod to small to medium businesses in stating that the cloud may make sense for them, the top line message was that cloud services overcharge for things that companies could do for themselves.  The piece ends up being a push for virtualization, and knocks Windows as a main cost issue for moving to the cloud.

Report Out

The report starts out with McKinsey’s view on the cloud.  They lay out that the premise for the cloud has been lower cost and faster time to market, but the reality is that these claims are overstated and that “cloud computing” is at the top of the Gartner hype-cycle.

The report takes it one step further to claim that since there is no agreed upon definition for what the “cloud” is (apparently they found a study that found 22 definitions for the “cloud”, which seems low to me considering the conversations I hear at conferences and on news groups), large companies should not think about “internal clouds” but rather focus on the immediate benefits of virtualization of servers, storage and network operations.  They posit that the newness of the cloud is distracting IT departments’ attention from technologies that “actually deliver sizeable benefits; e.g. aggressive virtualization.”

The early part of the report unfortunately spends as much time as many of the conferences are these days on the minutia of what definition is right, and what “the cloud means.”  More than anything, these diversions are tiresome for the observer and confusing for IT managers.  They zero in on the following traits:

1. Hardware management is abstracted
2. Capex to opex
3. Elastic demand for resources.

That sounds like what we presented at the Azure launch at PDC, but far be it from me to ask McKinsey to give Microsoft credit for the definition.

They call Windows Azure a cloud example, and not Azure Services Platform.  This confusion is consistent with customers and press/blogger sentiment that I am seeing.  Windows Azure is a piece of the overall Microsoft cloud play.  It’s an application hosting environment, which serves as the foundation, though not required, layer for other code execution paths in the Azure Services Platform.  One can build applications that live completely on-premises without using Windows Azure, but utilize other pieces of the Azure Services Platform.

They do call out the difference between a cloud and cloud services.  Cloud services has the two key tenets of hardware abstraction and scaling elastically.  The service could run on top of a cloud or not (e.g. SaaS).

McKinsey makes the mistake of confusing operating costs and startup costs.  The use of clouds by small companies is a result of startup costs, cost of capital, and availability of funds.  Those companies are the ones who are not already invested in large datacenters and likely lack the resources to build their own.  Whereas large companies have sunk costs in their datacenters, and will most likely externally claim that their operating costs are much lower than reality.  Over time, as they have to think about expanding and building new data centers with new equipment, large companies will most certainly then be looking at the cloud in much the same way that small companies are now.

McKinsey lays out the four main hurdles to adoption of cloud by large companies:

1. 1) Financial – cloud is not cost effective compared to large company datacenters (calculations to follow)
2. 2) Technical – security and reliability concerns, and re-architecting of apps.  I’m not sure about the first two, since they don’t offer any data (in which case, it’s a perception issue).  For re-architecting, this also is confusing.  Since AWS is essentially virtual hosting, you can move your apps to AWS with little to no work.  Azure is a different story, but AWS is the focus of this report.
3. 3) Operational – Perceptions of IT flexibility have to appropriately managed
4. 4) Organizational – org changes will be required to operate in a cloud world

The report claims the “typical” enterprise datacenter has the following metrics:

• · 10% utilization
• · $20M/MW
• · $.1 kW-hour
• · $14K/server (2CPU, 4 cores each CPU)

We finally get into the calculations for large and small/medium companies at slides 23-24.  They don’t show their calculations, but claim that the Total Cost of Assets for this typical datacenter is $45/month for CPU equivalent.  Assuming 36 month depreciation, that $14K server is $48/month.  Doing the math on Amazon’s Reserved pricing (for Linux servers – not available on Windows) yields:

McKinsey’s conclusions are simply wrong.  All of the instances work out to the same pricing per month, but vary depending on your agreed upon term of use (1 year or 3 years).  Importantly, assuming the 3 year depreciation schedule of their $14K server, the equivalent 3 year cost from AWS is $21/month/core.  This pricing does not include bandwidth costs, but I compare it to the $14K server purchase price.

Even more confusing is that on the two slides they have separate EC2 pricing conclusions for small/medium companies and large companies, even though they have the same line of demarcation for what is economical – the $45/s month per CPU month.  The boys at RightScale also take exception to the reporting of the numbers by McKinsey.

Page 25 is where things get interesting.  McKinsey claims that there’s a 144% gap from running one’s own datacenter to complete outsource to AWS (which is an unreasonable premise, as wholesale outsourcing is not the message delivered to any customer from any cloud player).  McKinsey then claim “the key factor is that the majority of servers that can be migrated are Windows servers.”  The implicit claim is that Windows makes AWS more costly.  A CIO takeaway may be “well, we have a ton of Windows boxes, so this won’t make sense.”  It’s true that AWS pre-made images running Windows are more expensive, especially if you include authentication services.  That’s for their pre-made images, and doesn’t take into account customers who have their own VL licensing. (NOTE: I am checking on our licensing policies here – it has been pointed out that license portability issues may be an issue)

On this same slide, McKinsey only attributes a 10% labor savings from moving to a third party provider.  They don’t substantiate that number, and it feels very light to me.  There is no talk of any of the automation that comes from moving to the cloud and using their tools for scale and elasticity.  Think tools like RightScale or Microsoft Systems Center.

McKinsey also knocks the uptime factor, claiming that enterprises set their own SLAs at 4 9s or higher.  In practice, this number is lower for any enterprise, but they have their own targets.  There are no web sources which track the downtime of enterprise resources, but there are a few for the cloud providers.  McKinsey claims that since AWS SLAs can’t match those of enterprises, enterprises won’t be interested.  There’s no punitive recourse if an IT manager doesn’t hit SLA, except perhaps that he might get fired, but AWS would be on the hook for real monetary damages, necessitating SLAs that are more realistic.  It’s easier to posture and claim you are designed for 4 9s than to say you have signed an SLA for 3 9s with a cloud provider.  4 9s, which is the enterprise target, allows only 52 minutes of downtime per year.  One server reboot a month could put you over that number.

On slides 29-30, McKinsey claims that large enterprises can increase their server utilization rates from 10% to 35% with “best in class, aggressive server virtualization.”  Additional cost controls can be gained, they claim, through adopting data center best practices, yielding TCO savings of 50%.

Finally, they liken the hype around cloud to that of the dot com bubble, and ominously point out that the NASDAQ fell 80% when that one burst, suggesting that CIOs should avoid investing in the cloud hype.

What’s Missing from the Report?

· The report lacks any mention of the massive economies of scale which come from a large cloud provider purchasing equipment.  Further, even things like the cost of power are glossed over, as our own internal $/kW-hour are much lower than those proposed for the “typical” datacenter.

· At present, AWS has near monopoly pricing power in the cloud, and it behooves them to keep those prices high.  With additional competition, prices will come down.

· There is no mention of the speed to market associated with procuring and provisioning servers for any new projects, nor is there any mention of the risk mitigation for new projects.

Additional Links

http://www.techcrunch.com/2009/04/16/mckinseys-cloud-computing-report-is-partly-cloudy/

http://www.roughtype.com/archives/2009/04/the_big_company.php

http://blogs.zdnet.com/BTL/?p=16384

http://www.forbes.com/2009/04/15/cloud-computing-enterprise-technology-cio-network-cloud-computing.html?partner=technology_newsletter

http://www.elasticvapor.com/2009/03/amazon-reserves-right-to-host-your.html

http://www.informationweek.com/blog/main/archives/2009/04/anticloud_hype.html

http://bits.blogs.nytimes.com/2009/04/15/when-cloud-computing-doesnt-make-sense/

http://blog.rightscale.com/2009/04/15/mckinsey-doesnt-get-the-cloud/

http://bizbox.slate.com/blog/2009/04/mckinsey_sez_cloud_computing_b.php

http://cloudpundit.com/2009/04/16/mckinsey-on-cloud-computing/

http://cloudpundit.com/2009/04/16/mckinsey-on-cloud-computing/

It should go without saying that the current financial crisis is going to loom large over the business plans of young and new software companies.  In fact, there is an article out that suggests that the removal of Lehman and Merrill from the buyer pool has reduced the IT budget of the financial services sector by 6%.  Let’s let that marinate for a moment.

It’s one thing to have a cyclical contraction in spending.  It’s another thing entirely to compound that problem with demand destruction.  Worse still, the demand destruction is not due to a symptomatic pricing issue, but rather the abject removal of key buyers from the market.

Even more complicating is the difficulties in financing businesses operations.  I’m not talking about raising venture money, but good old commercial credit.  Many companies use debt for expansion, and many times that expansion includes computer systems.  Companies are now having their hands forced to not just pay lip service to lowering their CapEx associated with IT, and moving it to OpEx.  They have no CapEx dollars left.  They need (must) find a way to fund software and services.  Enter SaaS business models, and the Cloud more broadly.  I would expect a knee jerk and rapid migration of buyers in the market to seek out SaaS solutions for line of business applications, and a reduction in spending on CapEx associated with IT.

Here’s the sad irony of the current financial debacle.  IT is what got us here.  IT has been wielded as an offensive asset for many of these firms.  The calculations required to price and model out many of the derivative products they were buying in insane.  I almost took a job at Merrill working on their Fixed Income Derivatives desk back in 1995.  Scary.  Here’s what’s more scary: my Fixed Income homework from my FNC235 class (*there’s a nod to all Wharton peeps who ever had Prof. Basak) is what got me the job.  The MD actually said “hire this guy.  I can’t make heads or tails of his homework and he got them all right.”

People worry about Google being the current incarnation of Skynet, but I would look more to the systems which have been handed the ability to make trades for humans based on human created models which very few people understand, much less can maintain in such manner as to adapt to what are being called 10 sigma events.

I was in NYC when 9/11 happened.  I remember a quote that still hangs with me: that we suffered a failure of imagination in our ability to stop the terrorist attacks.  There’s a similar sentiment to be had here.  The failure of imagination in the building of these models has led to many models essentially acting (reacting?) the same way, causing herd like behavior in a flight to or from assets.  The combination of programmed trading, naked shorts and no uptick rule has led to some serious unintended consequences.

If your cloud provider falls over, but you have no customers using your app, did it really fail?

It’s not so often than I get to poke fun at anyone (yeah, right), but in this day and age where it seems that the only way to get noticed is to have funny cartoons, I figured I would enlist the help of my super secret artisan resource, and poke some fun at our competition.

As I spend more and more time with our partner community discussing all things related to SaaS and PaaS, one topic comes up over and over again.  Having a proper Service Level Agreement (SLA) provided by any potential cloud provider is the most important item on the list of their required items.  The failures of the Amazon cloud (portal and web services) and Google properties (Apps, and App Engine) are well documented, and it has given pause to many of the potential developers in the IT Pro and ISV space.  Their main concern is what is going to happen if they deploy a service or application against that infrastructure?  Who’s neck do they get to choke?

Google App Engine has no mention of an SLA in their terms of service, and they know it.  The GMail guys have one, but like the Amazon S3 SLA (the only one of their web services to have an SLA), it’s 3 9s.  A good start, but not what the enterprise customers are going to need to instill confidence to move to the cloud.  The loss of control associated with moving to the cloud is a powerful disincentive for these developers, and without a higher degree of certainty over the uptime of the services consumed, moving mission critical, line of business applications and services to the cloud becomes a much harder discussion with the business decision makers.

The notable exception here is Joyent, who goes out on a limb to claim 100% uptime in their SLA.  The big issue here, unfortunately, is that as a provider on top of the Amazon services, they are at the mercy of Amazon and their ability to keep their servers up.  The pecuniary consideration Joyent is willing to pay out is not really well within their control, which is unfortunate, and it will be interesting to see how this plays out over time.  However, I definitely give them credit for putting that SLA out there.  The problem with writing late at night is you get your companies mixed up.  Joyent does provide SLA, but they don’t run on Amazon.  Big thanks to Rod at Joyent for keeping me honest on this one.  Joyent is running their own datacenters and have made significant investments across their 4 DCs.  That said, they have had some downtime, which is not unexpected.  It would be very interesting to know the economic impact of their January outage, but something tells me that Rod won’t be so forthcoming with that correction for me. <g>

The company I was thinking about that had tied themselves to the Amazon ship is RightScale.  They have a FAQ tied to their pass through SLAs with Amazon.  The challenge I have with their solution is that if you have access issues, you are advised to log in and launch more instances.  This doesn’t help you if datacenters fall over, power goes down, large scale DDoS attacks, etc.  This only helps for domain / app specific scaling issues, and even then, it doesn’t always solve your problem.

There’s a lot of work to be done in the cloud space, especially if the many business ISVs out there are going to think about porting some or all of their offerings to a platform provider.  The feedback from partners is very clear, and the online conversation backs up this assertion – SLAs are the first stop to winning the hearts and minds of the business ISVs and IT Pro developers.