Porting HPC Applications to Grids and Clouds - Cloud, Grid and High Performance Computing: Emerging Applications - page 35

Grid or in the cloud. Grid and cloud technologies
help to adjust an enterprise's IT architecture to
real business requirements (and not vice versa).
For example, global companies will be able to
decompose their highly complex processes into
modular components of a workflow which can be
distributed around the globe such that on-demand
availability and access to suitable workforce and
resources are assured, productivity increased,
and cost reduced. Application of Grid and cloud
technologies in these processes, guarantees seam-
less integration of and communication among all
distributed components and provides transparent
and secure access to sensitive company informa-
tion and other proprietary assets, world-wide. Grid
and cloud computing is especially of great benefit
for those research and business groups which
cannot afford expensive IT resources. It enables
engineers to remotely access any IT resource as
a utility, to simulate any process and any product
(and product life cycle) before it is built, resulting
in higher quality, increased functionality, and cost
and risk reduction.
Rule 2: Evangelize your decision makers
first. They are the ones who give you the money
and authority for your project. The more they know
about the project and the more they believe in it
(and in you) the more money and time you will
get, and the easier becomes your task to lead and
motivate your team and to get things done. Pres-
ent a business case (current deficiencies, specific
benefits of the Grid and/or cloud (see Rule #1),
how much will it cost and how much will it return,
etc). They might also have to modify existing
policies, top down, to make it easier for users (and
providers) to cope with the challenges of and to
accept and use these new services. For example,
why would a researcher (or a department in an
enterprise) stop buying computers when money
continues to be allocated for buying it (CapEx)?
This policy should be changed to support a utility
model instead of an ownership model (OpEx). If
you are building a national e-Infrastructure, for

example, convincing your government to modify
its research funding model is a tough task.
Rule 3: Don't re-invent wheels. In the early
Grid days, many Grid projects tried to develop
the whole software stack themselves: from the
middleware layer, to the software tools, to grid-
enabling the applications, to the portal and Web
layer…and got troubled by the next technology
change or by experts leaving the team. Today, so
many Grid technologies, products and projects
exist already that you first want to start looking
for similar projects, select your favorite (most
successful) ones which fit best your users' needs,
and 'copy' what they have built: and that will
be your prototype. Consider, however, that all
Grids are different. For example, research Grids
are mainly about sharing (e.g. sharing resources,
knowledge, data) and collaboration, commercial
enterprise Grids are about reducing cost and in-
creasing productivity and revenue.
Rule 4: Keep It Simple. It took your users
years to get acquainted with their current working
environment, tools, and applications. Ideally, you
won't change that. Try hard to stick with what
they have and how they do things. Plan for an
incremental approach and lots of time listening
and talking. Social effects dominate in Grids and
in clouds. Join forces with the system people to
change/modify mainly the lower layers of the
architecture. Your users are your customers, they
are king. Differentiate between two groups of
users: the end users who are designing and de-
veloping the company's products (or the research
results) which account for all the earnings of your
company (or reputation and therefore funding for
your research institute), and the system experts
who are eager to support the end users with the
best possible services.
Rule 5: Evolution, not revolution. As the
saying goes: “never change a running system”. We
all hate changes in our daily lives, except when
we are sure that things will drastically improve.
Your users and their applications deeply depend
on a reliable infrastructure. So, whenever you