RightScale Blog

Cloud Management Blog
RightScale 2014 State of the Cloud Report
Cloud Management Blog

Add new comment

Dear Thorsten, let me elaborate more on these concepts: Interoperability: yes, interoperability was the main requirement in Grid systems; it may be an indirect market request for cloud systems; clouds are born to enable flexible renting of an IT infrastructure, while Grid was born to share resources among different admin domains in order to solve problems requiring resources exceeding the individual capacity; Size of allocation: when I stated that I do not see this as an important factor, I was referring to the size of allocation in terms of number of nodes that a single user can require; in Grid systems, the smallest amount of allocation unit is a single job slot (which can be mapped to a single CPU); if the user asks 1, 10, 100 or 1000 slots does not change the meaning of using a Grid system; the Grid usage pattern is being able to require a job slot using a virtual identity (typically X.509 certificate) and then having the Grid system mapping this request to a real resource in some admin domain and mapping the virtual identity to a local account; for a user, this allocation is typically best effort within the resources available to the virtual organization (VO) to which the user belongs to. Each VO typically signs agreements with admin domains to have a certain amount of guaranteed resources and VO users compete for them. This is not the only allocation scenario. Advance reservation is also a reality, especially in supercomputing centers exposing their systems using Grid middleware. In Grid systems, you may find differentiation in the allocation strategies based on the length of jobs or group ownership of users. Several flavors exist and are appearing. Time-to-run: I agree when you say that clouds are mainly offering a real-time allocation mechanism as opposed to the best effort from Grid system. Cloud systems concentrate on on-demand scaling up and down for service allocation and pay-as-you-go as opposed to the job execution on shared resources. The company offering cloud system needs to over-provision based on some prediction model. If a cloud does not scale up on user demand and as written in the SLA, it fails. In Grid, there is more transparency on resource availability and the average number of resources is typically known. If Grid users wait in the queue, they do not complain given the fact they get what the VO agreed for. Another thought: when Grid was conceived, VM's were not a commodity, nevertheless they were not strictly needed (thought really beneficial; the Globus project has been working on VM exploitation since 2004, http://workspace.globus.org/papers/index.html). For clouds, virtualization is vital. Concluding, I agree with your last paragraph. Being able to "fork a server" from the programmatic viewpoint is opening to new appllications. The "resizable Grid" is an interesting application. We'll see in 5 years how they will affect each other.