Information Technology Reference
In-Depth Information
infrastructure, but provides no further benefits. For example, this does not allow users
to share data with each other, nor does it allow to make efficient reuse of intermediary
processing results, such as in live rendering - in short it does not allow for any
collaborative enhancements. It also does not allow for exploitation of concurrency
between individual functions, so that generally this creates no performance benefit.
Most enterprises and individuals consider transition to the cloud to improve service
quality however and want particularly to improve execution performance, reduce
resource costs to their minimum, and offer collaborative features. In such a case, any
of the options 2.-4. may apply, whereas complexity increases with the higher options.
To identify which options are possible, it is necessary to analyse the use case in
question. To this end, the dependencies between functional and data units need to be
analysed with respect to their potential for being distributed. Whilst model driven
architectures do provide some insight into these dependencies, the actual impact on
the criteria listed above can only be estimated and may vary during execution.
To gather meaningful data, the best approach consists in instrumenting the code or
by monitoring the memory behaviour as recommended and elaborated by the S(o)OS
project. The S(o)OS project furthermore indicates how this information can be
interpreted to the purpose of code segmentation, distribution and parallelisation: by
weighing access frequency and read / write patterns the degree of dependencies
(strength and density) can be qualified. Using this weight, segmentation cuts may be
performed in the code according to the communication (and exeuction) capabilities of
the destination platform [5].
We need to extend this model to investigate the impact of more or less arbitrary
access attempts via the externalised interface. This behaviour can either be simulated
and evaluated through actual memory usage, or propagated along the weighted graph
in the form of heuristic representations of the user behaviour.
The analysis of the respective application should in all cases be able to indicate
access frequency and size (density), as well as the dependency between request and
actual usage (strength). By furthermore annotating the data with respect to whether it
is expected to be shared between users, the analysis thus provides a fairly accurate
distribution architecture, including communication requirements and instance control
indicators. The according mechanisms will be investigated in the upcoming EC
funded research project PaaSage, and published shortly.
3.3
Interpreting the Results
Basing on the analysis, the use case's "cloud potential" can be assessed (respectively
the most suitable platform can be identified):
The code can principally be segmented where the expected control behaviour
changes substantially (i.e. a boundary between shared and non-shared functions /
data). For example, the graphical user interface of an application can typically be
easily segmented from the actual logic. In the application analysis graph this is
denoted through individual memory spaces per each external instantiation request,
rather than a shared memory region. These separate regions are an indicator that
either code and data, or just data can be maintained per individual instance, whereby
the trigger in this case may be the external request, i.e. user connection.
