<epilogue – the end as the beginning or conclusions first>
- Both the papers are well written and I thank the authors for the details as well as the e-mails. It is worth the cloud community’s time to deliberate and debate the concepts.
- IMHO, Grids and Clouds are conceptually distinct beasts; but if one squints long enough or one abstracts to the stratosphere, they might look the same. Let us call them Paczkis (Pronounced “punchkeys” ) on Paczki day, Grid on Grid days and Cloud, rest of the days ;o) And as a cloud expert once said, “that which we call a cloud, by any other name would smell as sweet”.
- Whether the grid domain is successful or not, I leave to knowledgeable folks like Ian to decide. Assuming grids have a large accidental complexity (which acts as barrier to entry), it is reasonable to conclude that, may be, clouds can simplify them – of course, now all grids will morph into cloud infrastructures, anyway ;o) And that is good – the cloud community also gets the experts and their experiences and thinking.
Parting question: Is the Hadoop infrastructure a cloud or a grid ? By the same extension would Google apps be grids than clouds ? ;o)
</epilogue>
<The gory details>
Now that we have covered the basics in the prologue, let us double-click couple of times. Jha, Merzky and Fox in their paper “Using Clouds to Provide Grids Higher-Levels of Abstraction and Explicit Support for Usage Modes” talk about the challenges with the grids and address complexity, interoperability, deployment support, They have done a good job of explaining a lot of the concepts.
I do disagree with a few of their statements viz “in some ways Clouds are the evolution of Grids”, “Cloud systems (or just Clouds) are, in some respects, narrow Grids” and agree with one statement “Cloud computing is a catch-all term for better contextualization, virtualization and most importantly simplicity of use” which they refer from the “Future of the TeraGrid” papers. Their definition of virtualization is a little weak, IMHO. But they understand the canonical cloud “A distinguishing feature of Cloud interfaces are that instead of exposing the largest possible amount of semantics for a specific domain, Clouds tend to expose a minimal amount of semantics to the end-user, while still being useful” – excellente ! While various Cloud infrastructure offerings do exhibit the characteristics of “affinity” as described by the authors, I am not sure “affinity” is a cloud artifact – layers of “affinity” may be. All their 3 observations are correct, but I can’t agree with the semantic ordering (Fig.2).
But the fundamental premise that grids can be saved by a cloud wrapper is questionable. I think, this could be hog in a tuxedo (I will leave the dissertation on pigs and makeups to politicians!) Remember, there is domain complexity and there is accidental complexity. I think the grid community has done a good job on the accidental complexity by various frameworks like Globus (even I had occasional contribution to the grid world). I think this is what Ian Foster is saying in his blog. And there are certain classes of problems addressed by grids and as per Ian’s blog they are doing well. No need for a cloud based tuxedo for grids, thank you ;o)
May be over reliance to WS-* rather than a REST architecture is the cause, may be the breadth and depth of the interfaces are complex, may be … this discussion I leave alone … it is for folks like Ian to debate and conclude.
Another interesting paper “Grids Challenged by a Web 2.0 and Multicore Sandwich” by Fox and Pierce, explains cloud as “Broad grid” (as opposed to “narrow grid” by Jha et al). They believe that grid “infrastructure is ripe for significant revisions”. I tend to agree with most of their observations viz “the problem of the next generation of computing will be an abundance (rather than a scarcity) of computing power for many problems”, “these clouds address ‘commodity usage’ rather than the high
performance simulations and data transport that are characteristic of Grids” and their insightful discussions on the trajectory and locus of massively multi-core systems (BTW, didn’t see two of my favorite topics Erlang and functional programming mentioned anywhere – CSP is mentioned, in passing ), You see, grids came from the world of high performance and parallel computing which is more related to the multi-core paradigms rather than virtualization and clouds.
On the notion of grids vs. clouds, my insights are in my previous blog Cloud Computing and Grids.
</The gory details>
<prologue – the beginning as the end>
The question “Is cloud a grid” has been discussed in detail in the cloud computing forms. The current crop of discussions swirl around Ian’s blog on paper by Jha, Merzky and Fox. Geoffrey pointed out another paper by Fox and Pierce in the same zip code. I did read both of them in some detail (need to think more as the papers have good depth) and here are some quick thoughts:
<relevance>
I agree that the discussion is somewhat orthogonal. Whether you call them grids or clouds or paczkis, providers will provide what makes sense for them and so is the case with cloud consumers. But, as I had said in one of my earlier blogs, our view of a domain has influence on our solutions – form follows the function. So, this is not an academic exercise but has pragmatic relevance. And, for a domain to grow, we need systemic disciplined definitions, interfaces and programming models.
</relevance>
</prologue>
—————————-
[Geoffrey07] Grids Challenged by a Web 2.0 and Multicore Sandwich
[IanBlog] A critique of “Using Clouds to Provide Grids…”
[Jha08] Using Clouds to Provide Grids…
[KrishnaBlog] Cloud Computing and Grids
[Paczkis] Pronounced “punchkeys”
