Information Technology Reference
In-Depth Information
the specific destination platform. Transformations such as this are very typical for
parallelisation efforts, where the developer attempts to make his code suitable for
HPC clusters in order to exploit the additional performance of supercomputers.
As has been shown, the key driver for cloud based applications is not performance,
but concurrency, availability and elasticity. The terminology of cloud providers is
often highly confusing with this respect: when talking about scalability, performance
and availability, they generally refer to the level of services typical for the web
domain. A user may however easily expect scalability and performance to the degree
of HPC. It must be stressed though that within the web service domain, clouds offer a
major improvement over alternative approaches. To effectively migrate applications
to the cloud, it is of utmost importance to be aware of this difference and to build the
application around these primary constraints.
On this basis, core functional building blocks can be identified that are most suited
for the cloud environment, respectively that relate better to other domains. Conversion
means can be identified that help identification and conversion of specific routines to
meet the environment's conditions best. Such information would allow the developer
to choose the right algorithms at design time; at the same time it would provide
indicators as to whether a certain application is principally suited for the designated
environment. Such efforts have been undertaken in the domain of High Performance
Computing for considerable time now, such as Berkley's report on key algorithmic
cores [2]. A similar attempt for clouds is now being initiated by the EC funded project
PaaSage, but essentially the necessary expertise is still lacking as of today.
Some indicators can, however, already be identified and may serve as a basis for
further elaboration. These indicators obviously relate strongly to the key criteria
identified within this paper, namely: scope, strength and density:
Scope (and implicitly scale) is impacted by the degree of sharing within the
application. One way of improving scope therefore consists in reducing strength and
density, as discussed below. Another way of improving scope consists in clustering
the logic, in alignment with the data dependencies, thus generating a modular
software structure that shows different scale within the different modules.
Strength is a major hemming factor in efficient usage of clouds, as the
communication delays must implicitly degrade performance. Programming models
generally do not allow differentiating between time for fetching and using data, thus
leading to the assumption that effectively data is available immediately. The effort to
compensate for strength must instead be taken by the developer.
The best way to approach this consists in using asynchronous messaging right from
design time. This automatically forces the developer to organise the code in a fashion
that caters for weak strength communication, and to exploit idle time for performing
other tasks. Asynchronicity also means that eventual consistency should be
considered for shared data, rather than immediate consistency. Notably, switching to
asynchronicity is not always possible, which could mean that the delay is secondary,
or that the application is simply not suited for cloud infrastructures.
Density plays a particular role in combination with strength: multiple messages or
huge messages can sum up in the performance degradation. Even if coupling is weak,
the mass of communication will create an impact. The key point for the developer is
to identify the right mix of number and size of messages - e.g. by packaging multiple
