When is a cloud not a cloud?

The answer to the question I've posed in my title is blindingly obvious, yet it seems to be one of those things that never hits you between the eyes until one day, something makes you stop and just think it through.

For myself, I've been giving this a lot of thought over the past 6-12 months, and recently I delivered a talk on the topic at CloudCamp London in July, called Captive Clouds Can't Connect (the clue to the answer is in the title). I've been thinking about it some more this month because OpSource [important disclosure] is paying me to write a white paper related to the launch today of its enterprise offering. Together with Amazon's announcement less than 48 hours ago of its Virtual Private Cloud, it has all brought this topic to a head.

So what is the simple, blindingly obvious answer to my headline question? It's this:

A cloud is not a cloud when it's not in the cloud.

OK, evidently, to make some sense of this answer, you need to be clear in your mind what you mean by 'cloud'. A lot of people — often for quite understandable reasons — feel very uncomfortable about the ramifications of moving computing to the cloud, and therefore they try and confine it within familiar boundaries where they feel more comfortable. They persuade themselves that, so long as they include some of the recognized characteristics of cloud computing, such as a virtualized infrastructure and some notion of metered usage, then they've still captured its essence, without having to stray beyond the confines of their existing enterprise infrastructure.

So let me take you back for a moment to the origins of the term 'cloud' and show you the flaw in that line of thinking. In the early days of the Internet, when people first started connecting their computer systems to this unknowable, amorphous, globally shared, wide area network, they represented it in their network diagrams with a simple, cartoon-style drawing of a small, fluffy cloud. Everything else in the diagram was a known entity, but the Internet, or the Web (if you were connecting at a software layer), was made up of an ever-changing constellation of autonomous components that was never going to stand still for long enough to describe it in any detail. The beauty of it was that you didn't need it to stand still (and didn't want it to, either). Just so long as you knew what you wanted from the cloud, you didn't have to worry what was going on inside it — and as time went on, the cloud kept on getting better — richer, faster and more powerful — without you having to do anything at all except making sure you kept your security measures up-to-date.

The essence, then, of this word 'cloud', is synonymous with the Web and the Internet — the shared, global computing network and all of the autonomous resources that participate in it. All the other attributes of cloud computing — the virtualized infrastructure, the pay-as-you-go pricing, the service-oriented architecture — count for nothing unless the computing is immersed in the public Internet and Web infrastructure — not just connected but truly in the cloud.

Because if it's not operating out there, outside the enterprise infrastructure and fully in the cloud, it will always be compromised. Sooner or later, someone will take a short cut on the scalability of the infrastructure, or the componentization of infrastructure services into consumable APIs, or the openness to readily connect to external services and resources as soon as they become available.

These days, I hear people talking about three kinds of cloud, one of which, as you may have gleaned from the discussion above, I don't consider as cloud computing at all. Private clouds, when the term is used to denote virtualized infrastructure contained within an existing enterprise infrastructure, are cut off from the core defining characteristic of cloud computing — the cloud itself. They are, as I warned the CloudCamp London audience last month, an abomination and a trap, to be avoided at all costs. I call them 'captive clouds' to convey their unhappy isolation.

At the opposite end of the scale, we have public clouds. These are cloud computing resources that operate totally immersed in the cloud, of which Amazon Web Services, Rackspace Cloud and now OpSource Cloud are all examples (perhaps Windows Azure, too — we'll know more later this year). Note, though, that a public cloud is much more than a bit of virtualized infrastructure plonked down in an Internet data center. So-called cloud offerings from managed hosting providers that aren't open to the Internet in the way I've sketched out above are just as inadequate and captive as any 'private cloud' set up by an individual enterprise. It doesn't make it a cloud just because you're running a link through the cloud to get to it. Cloud immersion is key.

This week has seen the unveiling of a third type of cloud, the 'virtual private cloud', as introduced by Amazon and OpSource. This is computing that operates within a public cloud but which uses virtual private networking to give individual enterprises the ability to mask off a portion of the public cloud under their own delegated control and management. There's clearly a need for this kind of capability, so that enterprises can begin to harness the benefits of cloud computing without having to expose their entire existing infrastructure to the public cloud in one fell swoop.

These virtual private clouds are not prone to the same defects as privately hosted 'captive clouds' because the underlying infrastructure is a shared public cloud infrastructure, and the demarcation is a reversible logical divide rather than a more permanent physical split. Done right, they allow enterprises to expose as much or as little of their virtual cloud domain to the public cloud as is appropriate to their needs. Bearing in mind those needs are likely to change over time, that makes this type of virtual private cloud a much better path — one that allows enterprises to not only have their own cloud, but have it in the cloud, too.