One of the most common complaints I hear regarding discussions of cloud computing is the malleability of the term. Many struggle with the fact that cloud computing can be and frequently is used interchangeably with other, related terms such as grid computing, utility computing, and even Software-as-a-Service. Further frustrating those who would seek a single, canonical definition of the term cloud computing is the fact that the different providers of what are generally agreed to be cloud offerings have taken significantly different approaches and architectures to market.
If you’re reading this and hoping that I’ve got the answer to that problem, you’re likely to be disappointed. This post is unlikely to correct that. Nor do I intend to endlessly debate definitions; after sitting in on one too many endless “What is Web 2.0” conversations, I’ve more or less lost my appetite for such academic debates.
That said, I believe that it is useful – indeed, necessary – to provide some structure to discussions of cloud platforms, because as noted above they are quite distinct from one another. And there is no shortage of people doing just that, with cloud definitional debates raging.
The definitions that are most closely aligned with those I use are probably Tim O’Reilly’s, taken from his entry entitled “Web 2.0 and Cloud Computing.” In the post, Tim defines three broad types of cloud technologies: Utility Computing, Platform-as-a-Service, and Cloud Based End-user Applications. My scope here is platform, so I’ll set the last category aside to focus on the first two.
We agree, I think on the big picture stylistic distinctions. But we appear to break on the importance of these distinctions; Tim seems to feel that they are aspects of the types, while I’m of the opinion that they instead define the type. For example, by Tim’s definition, one characteristic of Utility Computing style clouds is virtual machine instances, where my definitions rather centers on that.
Here’s how I typically break down cloud computing styles:
Fabric
Description: A problematic term, perhaps, because a few of the vendors employ it towards different ends, but I use it because it’s descriptive. Rather than deploy to virtualized instances, developers building on this style cloud platform write instead to a fabric. The fabric’s role is to abstract the underlying physical and logical archictecture from the developer, and – typically – to assume the burden of scaling.
Example: Google App Engine
Instance
Description: Instance style clouds are characterized by, well, instances. Unlike the fabric cloud, there is little to no abstraction present within instance based clouds: they generally recreate – virtually – a typical physical infrastructure composed of instances that include memory, processing cycles, and so on. The lack of abstraction can offer developers more control, but this control is typically offered at the cost of transparent scaling.
Example: Amazon EC2
The Net
The purpose here is not to argue the merits of one cloud style at the expense of the other. Each approach has its respective strengths and weaknesses, and I see them – unsurprisingly – as different tools for different jobs. While many have argued to me that the trend-line is towards fabric style platforms, I am of the opinion that both fabric and instance deployments will coexist for the foreseeable future. Which is probably obvious, since this piece would otherwise be a waste of my time and yours.
Do these definitions make sense to you? Do you have a better classification system?
Recent Comments