Cloud Types: Fabric vs Instance

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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:


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


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?


  1. nice timing – was just discussing / comparing / contrasting Google and Amazon approaches.

  2. 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).

  3. […] Stephen O’grady writes about two types of clouds computing: instance (Amazon EC2) or fabric (Google app engine). Interesting reading. […]

  4. 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?

  5. 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).


  6. […] at least vaguely cloud-like. And they are, along with Google, one of the notable providers of what I term a fabric cloud […]

  7. […] initial cloud offerings are instance rather than fabric-based and as such don’t involve a change in the programming model or style. An app isn’t going to […]

  8. 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.

  9. […] was my business partner Stephen O’Grady who made the simple Instance vs Fabric distinction, and I find it pretty useful in contextualising the cloud. Of course any instance cloud […]

  10. […] crammed in as well. For all the success of the Infrastructure-as-a-Service (what I’ve called instance clouds) play that is Amazon, more of the emerging platforms are Platform-as-a-Service (what I’ve […]

  11. […] crammed in as well. For all the success of the Infrastructure-as-a-Service (what I’ve called instance clouds) play that is Amazon, more of the emerging platforms are Platform-as-a-Service (what I’ve called […]

  12. […] O’Grady wrote up a nice post back in November called Cloud Types: Fabric vs Instance, where he described the Platform and Infrastructure layers as Fabric and Instance respectively. […]

  13. […] primary styles of cloud implementations, IaaS and PaaS – what I’ve previously termed instance and fabric – we’ve seen dramatically different economic opportunities. With IaaS, the […]

  14. The fabric model sounds very much like a grid. Or maybe a virtualized grid. Also not sure where fabric leave of an PaaS starts.

  15. All your ACID are belong to us…

    First hallucination
    The hallucinations category of this blog is what may be called a “vision” were it not obviously so “out there”. (Yes, the first hallucination is on the ACID subject, ha ha.)

    I was going to just write about t…

  16. […] a veneer on top of an Infrastructure as a Service offering – what I have previously termed a fabric. This fabric obscures the underlying complexities of the hardware and software infrastructure […]

  17. […] cloud fabrics, programming language proliferation, mobile application development and the spike in development […]

  18. 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)

  19. […] – the layer currently serving as middleware – is public cloud only. The PaaS fabrics tend to be proprietary and not available for private consumption. Salesforce.com, for example, […]

  20. […] – the layer currently serving as middleware – is public cloud only. The PaaS fabrics tend to be proprietary and not available for private consumption. Salesforce.com, for example, […]

  21. James – I believe you inherited the word from Paremus? i.e. the Paremus SERVICE FABRIC. We also demonstrated how our Fabric dynamically assembles required runtime middleware in response to the requirements of the business components – this prompting your “Stackless Stack” article???


  22. […] In its earliest incarnations, PaaS was a seamless if tightly constrained fabric which abstracted and made opaque the infrastructure running underneath it, from database to […]

Leave a Reply

Your email address will not be published. Required fields are marked *