Grid computing – юзеры делают малое количество больших вычислительных запросов. Например в лаборатории есть 1000-узловой кластер и юзеры запрашив…

Whether resources are provided immediately/real-time, as an advance reservation, or on a best-effort preemptbible basis is a property of a resource lease you choose to provide (the terms of service on a lease) but not a fundamental difference. Similarly, the size of a lease that you choose to provision is just another difference in terms. In the science clouds (http://workspace.globus.org/clouds/) we run at University of Chicago and Florida we get requests for leases of all shapes and sizes, wide and narrow, longer-term mixing happily with short-term and I would say all of our users right now come from the Grid community. And we can easily migrate them to EC2 precisely because the two services are nearly the same.

Having said all that — while I see cloud computing as an evolution of grid computing I do think it is a *significant* evolution. The focus on resource leases enabled by virtualization (what Thorsten I think refers to as “forking the server”) rather than scheduling jobs is a fundamental difference. The notion that you can create a custom environment and map it onto resources in an easily relocatable fashion will refactor the roles in what are now called grid communities. Five, ten years down the road I don’t think we will see any distinctions.

Best regards, Manuel Delfino, Director, PIC, Barcelona, Spain.

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.

I would disagree that the size of allocation isn’t an important factor. As you write, the grid world revolves around batch job scheduling. This is a fundamentally different paradigm from the real-time allocation that cloud offer. The control over your system and the type of systems that can be deployed are vastly different and fundamentally affect the way the applications are written as well as the way they are managed.

As I’ve mentioned many times, the most fundamental principle in cloud computing is being able to bring the next server from boot into full production on auto-pilot. This solves many problems, from repairing failures, to scaling up and down with load, to launching additional deployments for special purposes (staging, demo, test, etc). The notion that when you need additional resources you go and get them is different. It doesn’t exist in batch processing. It doesn’t even cross your mind. Programmers are used to fork a thread or a process, now they can fork a server.

I would not see the size of allocation as a factor for differentiating them.