Information Technology Reference
In-Depth Information
3.1
Classification Criteria
With respect to the preceding assessments, three major criteria stick out:
1.
Scope (degree of sequentiality, respectively parallelism)
2.
Strength (or “tightness” of the communication between instances)
3.
Density (or amount and size of exchange / communication between instances)
These three criteria can more or less be directly mapped to instantiation speed,
communication latency and bandwidth as elaborated in the first section:
Scope. The number of instances required and the number of instances maximally
possible (i.e. scalability) define the resource “hunger” of an application and therefore
its need for a larger infrastructure at all. We thereby need to distinguish between the
resource need of a single instance (parallelism) and the amount of instances required
due to the amount of requests / users (concurrency). The effective need is therefore
the product of parallel scope time concurrency scope.
Strength. The acceptable communication delay for any shared data access or
information exchange provides an indicator for the acceptable latency and therefore
for the type of infrastructure required. We can most of all distinguish thereby whether
the exchange is synchronous and therefore directly impacting on execution
performance, or whether the communication can be executed asynchronously, in
which case the impact on performance is considerably less.
Density. The communication delay in itself may have little impact if the amount of
messages, respectively data accesses is comparatively low and if the messages in
themselves are comparatively small. For example, even a synchronous, blocking
request of multiple seconds duration may be ignored, if it only occurs a few times per
hour, so that delay << execution time.
3.2
Analysing the Use Case
The benefit of the criteria provided above is that they can be extracted from a given
application in a fairly easy way, though their interpretation may not be as straight-
forward as the conditional cloud characteristics listed in the preceding section. In the
following we assume that the application has not yet been migrated to the cloud,
though the same principles would apply:
As has been noted multiple times, the cloud is an infrastructure consisting of
multiple dynamically allocated servers that can host an elastic number of application
and data instances, according to requirements. In order to exploit this infrastructure,
the following migration scenarios are possible:
1.
Keep the application standalone, sharing no data or code
2.
Share data between instances to allow for collaboration, networking etc.
3.
Distribute the code to allow partial sharing of functional logic
4.
Distribute code and data over the infrastructure
The general idea is to make use of multiple resources thereby creating a better user
experience. The simplest case is obviously 1), where no further actions have to be
taken and each instance is simply hosted in its full environment (image) - this
provides the service with considerable enhancements of availability through the cloud
