Massive economies of scale make cloud computing and storage inevitable. But if the scale required for economic clouds exceeds the capacity requirements of the largest enterprises “private clouds” won’t fly against their public counterparts.
Some cool implications:
- Clouds favor smaller users. Large enterprises have too many economic and contractual risks to embrace public cloud infrastructure.
- Public clouds are cheaper. As cloud technology evolves expect further increases in economies of scale that enable cloud providers to further undercut enterprise computing and storage costs while still earning a healthy profit on the services they provide.
- Small is beautiful. And profitable. The low costs of cloud-based infrastructure combined with the global reach of the Internet drive large enterprises to focus even more on what only large enterprises can do – like developing and marketing trillions of dollars of toxic securities.
McKinsey weighs in
Ken Brill and his merry band at The Uptime Institute have a McKinsey discussion document available for download called Clearing the air on cloud computing. It offers the most concise definition of cloud computing yet.
Definition: Clouds are hardware-based services offering compute, network and storage capacity where:
- Hardware management is highly abstracted from the buyer
- Buyers incur infrastructure costs as variable OPEX
- Infrastructure capacity is highly elastic (up or down)
McKinsey also makes a useful distinction between cloud services and cloud infrastructure. Cloud services comply with two of the key requirements: hardware abstraction and elastic infrastructure. In a service the buyers do not incur infrastructure costs as OPEX.
Under this definition cloud storage and cloud computing are both clouds. Application is irrelevant to taxonomy. Google app engine is a cloud computing. Gmail is a cloud service.
McKinsey has a couple of key observations:
Clouds already make sense for many small and medium-size businesses, but technical, operational and financial hurdles will need to be overcome before clouds will be used extensively by large public and private enterprises
Rather than create unrealizable expectations for “internal clouds,”CIOs should focus now on the immediate benefits of virtualizing server storage, network operations, and other critical building blocks
In other words, there is lower hanging fruit for large enterprises.
The StorageMojo take
If history is any guide cloud infrastructure will find its way into large enterprises the way PCs and before them minicomputers did: through the initiative of LOB executives.
Enterprise clouds such as Cisco’s new UCS promise to enable the glass house to compete with the cloud house. That strategy is necessary but not sufficient: internal clouds won’t have the scale and the capacity to offer internal customers the variable OPEX and the highly elastic capacity.
Yet the glass house need only provide a fraction of the flexibility of an Amazon to win most of the business – in the midterm. In the long term nimble competitors whose cost advantage comes from cloud computing will force large enterprises to outsource non-essential data intensive services.
Cloud computing is entering the peak of the hype cycle. A year from now many data center managers will be mocking the unfulfilled promise of cloud computing, just as they earlier mocked PCs, minicomputers and Ethernet.
Like those successful assaults on the glass House, cloud infrastructure will take a decade or more to flank large enterprise IT. Smart IT managers will stay tuned to the cloud’s inexorable economies of scale.
Courteous comments welcome, of course.
Private Clouds can make sense for the same reason that Virtual Machines make sense. Currently most companies have separate servers and storage for Oracle, Sharepoint, email, engineering compute farms and this, that and the other thing. Typically all these machines are physically distinct and often with different teams of IT pros maintaining them. Wouldn’t it be wonderful if a company could create its own compute cloud which could be shared by all of these teams using the same hardware, storage and networking infrastructure? Finance needs more horsepower for the end of month number crunching? No problem just use part of engineering’s share of the cloud for a day or so. With the current model the engineering compute farms are completely separate and giving finance the use of some of those resources for a day or two is impossible unless the IT folks have done an extraordinary amount of work to allow that to happen.
Terry, good points. The devil is in the details.
-Current chargeback software is a blunt instrument so IT won’t know who to charge for what. Without that the LOBs have no incentive not to pig out.
-Current infrastructure won’t be ripped out to make way for UCS or whatever – so you’re looking at a 10 year migration to the New Thing.
Just to be clear, I think that more integrated enterprise infrastructures are a good idea. What doesn’t fly is the idea that these enterprise-size infrastructures will be cost competitive with cloud infrastructures. For tx-oriented workloads that isn’t a problem. But for the mass of important but not urgent apps the Force will be with the Cloud.
Obi-Wan
Hi Robin,
I happened to be at the Uptime Symposium and saw Amy Wohl speak after McKinsey’s William Forrester. She has a different opinion too. She presented a clear summary of the pros and cons. See http://amys.typepad.com/amy_wohls_opinions_on_saa/2009/04/mckinsey-got-it-wrong-cloud-computing-is-for-enterprises.html
Robin,
Good article. You might think about challenging some of the assumptions people have about private clouds as well. Does “private” necessarily mean “privacy”? Or does private mean that I want hard allocated resources that are always available for my needs?
I don’t see any technological barriers to achieving the kind of security and privacy that corporations need in a hosted environment. What I have seen is vendors slapping “private cloud” slides at the beginning and end of their standard storage product pitches.
One of the first things I envision the new SNIA Cloud TWG doing is separating some this hype from the reality with models and taxonomy that can be used consistently. Keep up the good work.
— mark
“McKinsey also makes a useful distinction between cloud services and cloud infrastructure. Cloud services comply with two of the key requirements: hardware abstraction and elastic infrastructure. In a service the buyers do not incur infrastructure costs as OPEX.”
Okay, I’ll bite. What *do* they incur them as?
If the alternative is CAPEX, does that mean that “cloud services” is another name for “private clouds”?
Alan
I think you need to distinguish between “private clouds” and “privately run clouds”. The former would just be virtualises, ring-fenced bits of a wider public cloud in the way that VPNs are related to public networks. A “privately run cloud” would, of course, be a corporate cloud run by an enterprise.
As far as economy of scale is concerned, then the real issue is going to tbe the development and implementation effort of these things, not the actual hardware costs. Amazon can afford to spend lots of money developing this and putting all the operational systems in – other enterprises won’t, or maybe will decide their money can be spent elsewhere. There will bea lot of pain in this stuff – as many enterprise who have dealt with outsourcing have found, it’s fraught with issues around contractual issues, service matters, communications and so on. Without a “standard” cloud model then portability between different suppliers is going to be a big issue, and there is a good chance of vendor lock in.
However, the analysis that LoB budget holders will drive this in the Enterprise is spot one, largely because there is always a problem with internal system costs and delays versus and more flexible and faster external offering without the need to deal with capital approval issues. Many companies are going to find themselves dependent on “cloud deals” for apps that have crept into the mainstream of processing. Very likely these will be hosted on different cloud-providers infrastructure unless the relevant corporations are particular good and quick at getting this under control. End to end service management of the resultant hybrids of apps hosted internally interworking with other apps running on a diversity of different cloud providers infrastructure is going to be a management challenge.
What we are going to see over the next several years is a shift – probably not a net reduction – in OPEX as companies/LOBs haphazardly move their applications into disconnected, incongruous “third party clouds”.
Expect to see application development, support and integration costs, as well as bandwidth costs, rise considerably.
In my opinion, what internal, “privately run” clouds lack in highly elastic scale and capacity [relative to their public cousins], they more than make up for from an application development and support perspective alone.
Steve, as for cloud vendor lock-in…it’s a red herring. Lock-in is a by-product of complexity regardless how many APIs and “standards” we throw at it. Name a large company that isn’t somewhat “locked in” to its relatively complex environment whether it was outsourced or in-sourced? Moving into the cloud, and from cloud-to-cloud will never be inexpensive or without pain.
@Joseph Martin
Agreed that vendor or technology lock-in is an issue whatever you do. However, and organisation with good architectural control can at least manage some of the issues. I recall having the discussions a long time ago over internal diversity of, for instance, databases or server architectures vs the monoculture approach. In theory the first gives you leverage on competion, price and quality. In practice you often just find yourself with multiple lock-ins to different vendors on legacy technology (and at premium price support).
The issue with “clouds” is two fold. Firstly if this does progress by LoB budget holders, then we can expect to see a diversity of suppliers being used be enterprises (we have been there, done that, and seen the proliferation of apps in office broom cupboards that resulted when there wasn’t some management). Secondly, you need to have a high degree of confidence in the stability and service of any of these cloud suppliers. I doubt any of them will be allowed to fail completely – presumably we’d get the same industry consolidations as we see in other areas of technology.
Of course these issues apply to almost every area of technology – just how many computer architectures have died in the last 20 years? But I think this issue of managing the architecture of your applications and their exposure to changes outside your control needs to be considered.