Defining the true meaning of cloud
In the midst of the Enterprise Irregulars discussion that ensued from Michael Krigsman's Monday blog post Cloud-based IT failure halts Virgin flights — when many of us complained it wasn't a cloud instance at all — Michael posted this plea:
"How does one determine whether a solution is 'cloud' or not — what are the rules?"
It's a fair question. When explaining cloud, I often allude to the ancient Indian parable of the blind men and the elephant, in which each man grabbed a different part of the elephant and, because they didn't see the whole creature, took it to be something quite different. The point being that cloud is exactly like that, and most of the definitions out there get it wrong because they focus on a part rather than the whole.
My definition highlights four components, which I'll set out below in a moment (or hear me explain them in this webinar, which I recorded last week). Three of the four components are often talked about individually, and the fourth is too often neglected altogether. The neglected component is one that I call 'cloud scale', and it's the one that sets the all-important context in which all the others come together as a unified whole. Yet it's the one most often ignored or denied, especially when people try to implement what they perceive as cloud on a private computing stack. What I say to them is almost becoming something of a catchphrase: "You can't take computing out of the cloud and still call it cloud computing."
The whole point of cloud computing is to be able to operate in the cloud — in that global, 24x7, connected universe where you can instantly reach and interact with your customers, your partners and your mobile employees, as well as tapping into an expanding cornucopia of third-party resources and services that can help you achieve business results faster, better and at lower cost. Those who say that cloud is just a deployment choice, just a technology option, have shut their eyes to the wider opportunity and potential that the cloud context opens up. They're still building application platforms and business systems that are designed without any acknowledgement of that global web of connections and resources — as if in today's business environment, being connected is just an afterthought, an optional extra. Maybe for some applications it is, but their numbers are shrinking daily.
Page 2: The 4 defining features of cloud »
« Page 1: If it's not in the cloud, it's not cloud computing
So having set the scene, let's walk through the four components that make up my definition of cloud.
Abstracted infrastructure. In most cases, that means virtualization, but I've chosen a slightly more generic term because virtualization implies a specific technology choice and the key point here is that the underlying infrastructure isn't tied to any specific hardware or operating software. In theory, any component could be swopped out or exchanged without affecting the operation of whatever is running above. Crucially, the abstraction provides elasticity to scale usage up or down without having to stop to upgrade the underlying infrastructure.
As-a-service infrastructure. The pairing of virtualization with automated provisioning and management has been a crucial element in enabling the on-demand, pay-as-you-go nature of public cloud. When enterprises talk about implementing private cloud, these are the ingredients they focus on, and there's no doubt that they deliver enormous cost savings and productivity gains when implemented privately. But these components alone are not the only constituents of cloud. Taking existing platforms and applications and implementing them on a pay-as-you-go, virtual machine is not cloud computing. You'll still have enormous extra management overhead, duplicated resources and wasted redundant capacity — and gain none of the additional benefits of a fully cloud-scale environment.
Multi-tenancy. Sharing a single, pooled, operational instance of the entire top-to-bottom infrastructure is more than simply a vendor convenience; it's the only way to really achieve cloud scale. Look beyond the individual application or service and consider also the surrounding as-a-service infrastructure and any connecting framework to other cloud resources. Understand the value of having all of that infrastructure constantly tuned and refreshed to keep pace with the demands of its diverse user base across hundreds or even thousands of tenants. The most conservative among them will constantly probe for potential risks and weaknesses. The most progressive will clamor for new functionality to be brought into production as rapidly as possible. Every tenant benefits from sharing the collective results of those two extremes and all points in-between, keeping the shared infrastructure both battle-hardened and future-proofed. Every tweak and enhancement is instantly available to every tenant as soon as it's live.
Cloud scale. It's no accident that cloud architectures are multi-tenant — just look at Google, Amazon, Facebook and all the rest. If you start from a need to perform at cloud scale, you build a multi-tenant infrastructure. It's the only way to deliver the walk-up, on-demand, elastic scalability of the cloud with the 24x7 reliability and performance that the environment demands. Cloud scale consists of all of this globally connected operational capacity, coupled with the bandwidth and open APIs required to effortlessly interact with other resources and opportunities and platforms as they become available in the global public cloud. A computing architecture can have all the other attributes of cloud, but without this cloud scale dimension, it will not be able to keep pace with the operational demands, the overwhelming connectivity and the continuous rapid evolution of the cloud environment.
Also read: