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?
Related posts:
7 Comments
nice timing – was just discussing / comparing / contrasting Google and Amazon approaches.
So I read your blog as:
Fabric – is essentially PaaS (platform as a service) – billed by CPU cycles , transparent and scalability , less flexibility in terms of choice of languages and DB
and Instance is – HaaS(Hardware is a service) – billed by Clock time , Automatic Scalability but not necessary transparent and more flexibility in terms of choice.
More on the stack here – http://www.gandalf-lab.com/blog/2008/10/comparing-appengine-ec2-and-caroline.html
What I do not get is – Why does Cloud Computing need to have a granular definition that describes the exact styles. Just by the choice of the word “Cloud” it signifies a loose definition and essentially something outside(of department , LOB ,Enterprise , home , or essentially not my problem). It really goes back to the service model. Everything is a service and it depends at what level you come in(Network device , Software , Platform or hardware).
I *love* this distinction, and it led me to an interesting observation of my own: if fabric hides infrastructure, while instance delivers infrastructure , won’t developers who have decision making on the cloud to use choose PaaS, while system administrators with the same control choose IaaS?
If so, who will win the right to choose in most enterprises?
Great post.
Another observation is that the two types are not mutually exclusive. You can run a Fabric type cloud (e.g., GigaSpaces) on top of an instance-type cloud (e.g., EC2).
Geva
I agree with Geva – Fabric is not mutually exclusive from instance. We (http://www.egenera.com) create a fabric by abstracting-away I/O, network and CPU. In that way we can scale instances… but without the programmer needing to know. And, the fabric is also agnostic to whether the instance is physical or virtutal. Fabric is therefore an ideal IaaS vehicle.
The fabric model sounds very much like a grid. Or maybe a virtualized grid. Also not sure where fabric leave of an PaaS starts.
Nice clarification. Some of the commenters have suggested that instance style equates to IaaS, while fabric style equates to PaaS. From your writeup, I think I would generally agree. However, Amazon’s recent feature-adds, the RDBMS and .NET SDK, are more characteristic of PaaS. Perhaps it is possible to be instance style but maintain characteristics of both.
Is Amazon moving in the direction of PaaS or are these features simply a preemptive response to the upcoming release of Microsoft’s Windows Azure Platform (a PaaS and fabric style service)? It will be interesting to see what happens in the industry over the next few years.
(I am contracting for M80, working with Microsoft to promote Windows Azure)
11 Trackbacks/Pingbacks
Post a Comment