Just don't call them private clouds
I don't like the term "private cloud." My reason is straightforward. The big-picture concept underpinning cloud computing is that the economic efficiencies associated with megascale service providers will be compelling. And, conversely, because they lack the scale of big providers, local computer operations will operate at a significant cost penalty.
To use the electric-utility analogy popularized by Nick Carr and others, efficient power generation takes place at a centralized power plant, not at an individual factory or office building.
There's ongoing debate about just how important these scale effects are and what form, exactly, they take. However, if one accepts this fundamental premise of cloud computing, then the future of computing lies predominantly in multitenant shared facilities of massive size. (Size here refers not necessarily to a single physical facility but to a shared resource pool that may, and probably will, be geographically distributed.)
In other words, a "private cloud" lacks the economic model that makes cloud computing such an intriguing concept in the first place. Put another way, the whole utility metaphor breaks down.
This is not to say that all computing will take place off-premises through these large service providers. In fact, there are lots of reasons why a great deal of computing will continue to happen locally.
For example, Chuck Hollis, global marketing chief technology officer at EMC, writes in The Emergence Of Private Clouds:
IT organizations and service providers that use the same standards will eventually be able to dynamically share workloads, much the way that's done in networks, power grids, and distribution today.
Fully virtualizing traditional enterprise IT internal resources creates substantial advantages--that much is becoming clear.
And if you're an outsourcer or other IT infrastructure service provider, the advantages of virtualizing your capabilities to do multitenancy better is probably clear as well.
And in a post titled "The argument for private clouds James Urquhart of Cisco Systems (and a fellow CNET Blog Network blogger) argues that:
Disruptive online technologies have almost always had an enterprise analog. The Internet itself had the intranet: the use of HTTP and TCP/IP protocols to deliver linked content to an audience through a browser. The result was a disruptive technology similar to its public counterpart but limited in scope to each individual enterprise.
Cloud computing itself may primarily represent the value derived from purchasing shared resources over the Internet, but again, there is an enterprise analog: the acquisition of shared resources within the confines of an enterprise network. This is a vast improvement over the highly siloed approach IT has taken with commodity server architectures to date.
The result is that much of the same disruptive economics and opportunity that exists in the "public cloud" can be derived at a much smaller (scope) from within an enterprise's firewall. It is the same technology, the same economic model, and the same targeted benefits, but focused only on what can be squeezed out of on-premises equipment.
I do have a couple of quibbles:
- Data center architectures are indeed getting more modular and more dynamic. However, it seems an unreasonably large step to take this overall direction and lump it under the cloud-computing banner. If any arbitrary data center environment is considered a "private cloud," then the already fuzzy term surely loses all meaning.
- While there are cloud concepts that can be rolled into in-house operations, the fundamental model posited by cloud computing assumes a shared utility. Returning to the electric utility metaphor, individual companies can install their own electric generators that are compatible with and can interoperate with the public utility. Doing so takes advantage of the standards in the delivery and consumption of power. It also provides a backup in the event of power failures. But these smaller generators do not deliver power as cost effectively as the utility can.
But I mostly agree with the overall sentiment of these posts.
Applications and services will continue to run both inside enterprise firewalls and in the cloud for reasons of technology, switching costs, and control.
On the technical front, many of today's applications were written with a tightly coupled system architecture in mind (for example, a high-performance fibre channel disk connected to large SMP servers) and can't simply be moved to a more loosely coupled cloud environment.
For existing ("legacy") applications, there's also the switching cost and time to move to a new software model. In fact, one of the big arguments for standardized, outsourced IT--allowing companies to focus on their competitive differentiators--can also argue against making investments to change functional software systems (and their associated business processes), especially if the financial benefits are long-term and somewhat amorphous.
Security and compliance are also major concerns today. We can argue about the degree to which they're justified. But ultimately, perception is reality.
And there is a certain convergence between how many applications run in the cloud and how they run in the enterprise. Web standards and virtualization are major drivers here, and they certainly make a degree of interoperability and mobility between enterprise and service provider (over time) entirely thinkable.
Existing applications (and operational procedures associated with them) change slowly, and many of them will continue to run inside corporate firewalls as a result. We'll also start to see "federated" and "hybrid" architectures that bridge the enterprise data center and the shared-services provider. Cloud computing will evolve in concert with enterprise applications, not in isolation from them.
But we shouldn't lose track of the fact that cloud computing is posited to be a disruptive change to the computing landscape. If that is the case, then the "cloud" moniker shouldn't be slapped onto evolutionary changes to the way we run applications.
Gordon Haff is a principal IT adviser at Illuminata and has more than 20 years of IT industry experience. He writes about what's happening with enterprise servers and data centers, "Yotta-scale" computing, and related software and device trends as part of the CNET Blog Network. Disclosure. 
And, I'm definitely behind the "thinkable" idea you mention of interoperability and mobility between enterprise and service provider. Hybrid or federated clouds, though, will either have to be pretty simplistic to start or won't make much progress until there has been more advancement in both the internal and external cloud capabilities. And, there will be some interesting stuff needed to manage the movement between the two. Policy-based, automated, etc. Last link (I promise), this time on the timing of hybrid clouds: http://datacenterdialog.blogspot.com/2009/01/publicprivate-hybrid-cloud-computing.html
"then the "cloud" moniker shouldn't be slapped onto evolutionary changes to the way we run applications."
Or, maybe, you can go deeper in the "cloud methaphor."
Why call them "private" if there is a rich tradition in meteorology?
From Mac OS X Dictionary:
"cirrus |?sir?s|
noun ( pl. cirri |?sir??; ?sir?|)
1 cloud forming wispy filamentous tufted streaks (?mare's tails?) at high altitude, usually 16,500?45,000 feet (5?13 km)."
"cumulus |?kyo?my?l?s|
noun ( pl. -li |-?l?; -l?|) Meteorology
a cloud forming rounded masses heaped on each other above a flat base at fairly low altitude."
"nimbus |?nimb?s|
noun ( pl. -bi |-?b?| or -buses )
1 a luminous cloud or a halo surrounding a supernatural being or a saint.
? a light, aura, color, etc., that surrounds someone or something.
2 a large gray rain cloud : [as adj. ] nimbus clouds."
(Take this as a "fuzzy" definition: 1 "luminous cloud" 2 "grey cloud")
I certainly understand the appeal of the private cloud notion. And I understand why folks who are used to selling gear to enterprises (and less so to service providers) are pushing it so. I know I'm being a bit of a purist but, if it ultimately doesn't really matter economically whether computing happens inside or outside the firewall, then the big picture cloud computing metaphor is a bit of a bust.
And, yes, the whole automagical interoperability thing is a ways out. Bob Sutor put up a post today on some of the standards he thinks will be needed.
If I have an application running on an IBM Cloud, how do I move that to Amazons Elastic Compute Cloud? Or if I have data in Googles Cloud (in BigTable) how do I move that to a HP Cloud service??
The current answer of course, is that you cant, you are completely locked in. Has any one heard of any standards being drafted or discussed to address any of these things? At the moment all the current/likely cloud providers are following exactly the same walled garden model that telcos and ISPs started with, the only difference being that cloud interoperability is orders of magnitude more complex - I really cant see it being solved within 10 years, if ever.
and surely that's enough to kill the "pure" cloud model dead right away??
Am I ill informed or being too pessimistic??
So choosing where to deploy a green field application becomes a measure of TCO, which may or may not go in the cloud's favor.
Besides, trust is the biggest issue enterprises face when looking to the cloud. I've made the case recently that trust will be the number one issue in cloud computing for the next year (or two, or three). There is no way you would look to leverage cloud economics unless you trusted the providers first.
I expect to see both lock-in and trust issues fall one by one over the next few years.
Bob seems to have a very pragmatic view of standards in this space (which is to be applauded) but again, there seems to be very little real activity here: no W3 or IEEE working groups established and there don't even seem to be any corporate initiatives either (like MS and IBM basically jump starting the web services space when they sat down and sketched out standards that were then quickly adopted by the rest of the industry) I cant think of any other technology development that has got so far without any meaningful development or discussion of standards....
Anyway, I'll get down off my soap box now :-)
The utility model favors the big-server-center vendors precisely because they can afford the licensing and because they can afford a large surface area of skills and talents when working in mixed platform environments. That is the fly in Sutor's ointment. Open source has a high TCO of skill sets and standards can't be left until a winner emerges. The 3D virtual worlds market is a good example. Standards exist. IBM ignores them claiming it isn't time for standards. The only beneficiaries are the IBM clients or proteges such as Second Life. Once again, qui bono? In this case, only the services vendors and their cloud or keiretsu.
Cloud computing works in the sense that the Internet works. As a business model, it works only for those who don't have to risk the indemnity issues for services. I think we are being taken for another ride on the Web Myth Train that tends to load people up and take them some place without any guarantee they can come back. That said and putting the economies of scale that cause the network to turn into megacenters, part of what is missing is the legal framework that enables cloud computing to be reliable computing.
Excellent insight. I will simply agree to disagree on this, as I just don't agree that the core value proposition of cloud computing is simply "someone else does it". To me, the "cloud" comes from the abstractness of the resources, and the self-service network-based methods of acquiring and operating those resources. I don't subscribe to "cloud equals Internet".
So for me, the "Internet/Intranet" metaphore works perfectly. Same technology disruption, but applied to a limited scope.
That being said, if you read Chuck's post carefully, he is changing the definition of "private cloud" to represent "within enterprise trust boundaries" rather than "behind enterprise firewalls". That is an interesting distinction, as it allows "private clouds" to run entirely outside of enterprise-owned infrastructure, as long as the enterprise has the *illusion* that they are managing their own data center/platforms/applications.
It's a concept that I can get behind.
Good to see you in California. I agree that there are architectural aspects to cloud computing that you can think of as a sort of Web-based SOA that are probably a better way of composing applications (and therefore have an economic benefit in and of themselves). I actually don't think that we collectively have a particularly good understanding of the economies of scale and multi-tenancy relating to cloud. In short, that argument for cloud computing may simply be wrong--at least as it relates to many business apps at large enterprises. It would be a bit funny if it turned out that cloud computing is a generally good thing but we were marching to it for at least partly the wrong reasons.
- by samjohnston January 29, 2009 5:36 PM PST
- Hear hear! Cloud computing is all about hiding complexity and economies of scale. If you build your own next-generation datacenter and bolt an Amazon EC2 style API on top of it then you have successfully concealed complexity from your internal users, but someone in your organisation still has to care about it and you're still paying them to keep the thing alive. This centralisation and consolidation is the evolution of virtualisation, not the revolution of cloud computing.
- Reply to this comment
-
-
- by ghaff January 29, 2009 9:38 PM PST
- Exactly. We may well decide that the electric utility analogy is a flawed one, but if "The Big Switch" storyline is fundamentally correct it's hard for me to see how private clouds are clouds--at least from an economic model perspective.
-
-
(14 Comments)To reuse the electricity analogy, the only places we're seeing generators still being deployed are backups for mission critical infrastructure (datacenters, hospitals, etc.) and in those few places that remain off grid. Perhaps the few datacenters that remain in 10 years will be deployed for the same reasons - backups (of data rather than service) and off-grid deployments.
It's worth noting too that most of the proponents of this oxymoron are peddlers of "I can't believe it's not cloud", and usually aren't shy of squeezing in healthy doses of FUD about trust, security, etc.
Sam