![](https://csdnimg.cn/release/download_crawler_static/3741923/bg14.jpg)
1 Grids, Clouds, and Virtualization 3
Desktop supercomputing included applications coupling high-end graphics ca-
pabilities with remote supercomputers and/or databases; smart instruments are sci-
entific instruments like microscopes, telescopes, and satellites requiring supercom-
puting power to process the data produced in near real time. In the class of collab-
orative environments there were applications in which users at different locations
could interact together working on a supercomputer simulation; distributed super-
computing finally was the class of applications requiring multiple supercomputers
to solve problems otherwise too large or whose execution was divided on different
components that could benefit from execution on different architectures.
The challenges to be faced before metacomputing could be really exploited were
identified as related to the following issues:
• scaling and selection;
• unpredictable structure;
• heterogeneity;
• dynamic behavior;
• multiple administrative domains.
Interestingly (from a research perspective), these are still relevant today. Scal-
ing is a concern, because we expect that grid and cloud environments in the future
will become even larger, and resources will be selected and acquired on the ba-
sis of criteria such as connectivity, cost, security, and reliability. These resources
will show different levels of heterogeneity, ranging from physical devices to system
software and schedulers policies; moreover, traditional high-performance applica-
tions are developed for a single supercomputer whose features are known a priori,
e.g., the latency of the interconnection network; in contrast, grid and cloud applica-
tions will run in a wide range of environments, thus making impossible to predict
the structure of the computation. Another concern is related to the dynamic be-
havior of the computation [51], since we cannot, in general, be assured that all of
the system characteristics stay the same during the course of computation, e.g., the
network bandwidth and latency can widely change, and there is the possibility of
both network and resource failure. Finally, since the computation will usually span
resources geographically spread at multiple administrative domains, there is not a
single authority in charge of the system, so that different scheduling policies and
authorization mechanisms must be taken into account.
In the same years, a middleware project called Legion [33] promoted the grid
object model. Legion was designed on the basis of common abstractions of the
object-oriented model: everything in Legion was an object with a well-defined set
of access method, including files, computing resources, storage, etc. The basic idea
was to expose the grid as a single, huge virtual machine with the aim of hiding the
underlying complexity to the user. The middleware proved to be useful in several
experiments, including a distributed run of an ocean model and task-farmed compu-
tational chemistry simulations. However, it became immediately apparent that the
majority of the people in academia were not fond of the grid object model; con-
sequently, the attention shifted toward the use of the Globus Toolkit, which a few
years later provided an alternative software stack and became quickly the de facto
standard for grid computing.