1 reply Latest Post - ‏2008-08-22T22:04:31Z by SystemAdmin
783 Posts

Pinned topic Grid Computing versus Cloud Computing...

‏2008-07-17T13:52:45Z |

I recently posted an answer to blog post that tries to position "Grid Computing" and "Cloud Computing" ( Since I mention Compute Grid, I thought I should post it here as well:

I see "Grid Computing" as the coordinated execution of a complex task across a collection of resources. The burden of the "grid" is to provide control over that execution (initiating the execution, stopping the execution, aggregating results of the execution, reporting the status of the execution, and so on).

The "grid" should be transparent to the end user. Take SETI@Home for example. The "User" is the researcher that will analyze the results of all of the computations. The SETI@Home platform manages partitioning the data into discrete chunks, dispatching & monitoring the results across the collection of CPU's spread across the world, and aggregating the results to provide a single view to the "user".

Cloud Computing on the other hand provides the virtualized infrastructure upon which the Grid Endpoints will execute. So for example, the "cloud" would provide an "infinite" number of operating system images on which the SETI@Home software would execute. The cloud shouldn't care about application-specific data, nor should it care about the business logic that is actually executing within a virtualized image. The cloud cares about allocating new images (synonymous to LPAR's) for applications to run, keeping track of how much physical resources (actual CPU cycles for example) the virtual images consumed, cleaning up the virtual images upon completion, and billing the client for the amount of resources consumed. So with these definitions, going back to my example of SETI@Home, I would argue that this software has both a grid computing component as well as a cloud computing component, where the # of registered computers is part of a pool of hardware resources that already have the SETI@Home grid application containers installed and ready to go), but we should be sure to see 2 separate components and responsibilities: the decision to pick a physical machine to dispatch to, and the grid container that executes the scientific processing.

To summarize, grid applications and therefore the "Grid Computing" paradigm, which I consider an application architecture and containers for running the business logic, would execute on top of an "infrastructure cloud", which appears as an infinite # of LPAR's.

BTW, we've had the ability to run'private clouds' for 30-40 years - multi-tenancy via S/390 & MVS - and we do it all over the place today. The key difference is that today, w/ Amazon EC2 for example, we can dynamically create and then destroy complete 'LPARS' relatively cheaply; whereas in the mainframe and other big iron hardware, LPAR's tend to be statically defined. In both cases the hardware is virtualized under the covers, some sort of VM/hypervisor contains the operating system image, some type of application server or container executes the business logic, and some type of workload manager assures workload priorities and provides the chargeback.

I've alluded to some of this in my article on 'enterprise grid and batch computing': 4_antani/0804_antani.html.

The Parallel Job Manager (described in that article) in WebSphere XD Compute Grid would essentially be the Grid Manager, whose job is to coordinate the execution of complex tasks across the cluster of resources (Grid Execution Environments). Today we don't discuss the ability to dynamically create new LPAR's (and therefore call ourselves a cloud computing infrastructure), but you can easily do this with a product like Tivoli Provisioning Manager. Basically, take the bottom image in my article: al/0804_antani/0804_antani.html#xdegc and connect Tivoli Provisioning Manager to the On-Demand Router (part of WebSphere Virtual Enterprise).
Updated on 2008-08-22T22:04:31Z at 2008-08-22T22:04:31Z by SystemAdmin