Database Reference
In-Depth Information
alize them, and are both accessible via the Internet. VPN could apply). So what are the
distinctive cloud promises?
• Generally, computing resources today are vast but unevenly loaded. At the same
time, speaking about a single enterprise, IT resources (SW and HW) are usually
provisioned according to average workload estimates (one/five year forecasts).
The Average Order Handling system designed for 25K orders daily will have a
hard time during peak loads (100K after an aggressive advertising campaign), so
the SLA will be broken with rather unpleasant consequences. It would be nice to
have the possibility to delegate the processing dynamically to order service in-
stances available on remote resources.
• Following the logic presented in the preceding point, the management can recon-
sider the resource allocation estimation model, setting it for the next period not
average but minimal requirements for on-premise application farm. The applica-
tion farm on cloud will be allocated gradually, depending on the current require-
ments. Internal resources will keep business knowledge in-house, and HW ex-
penses will be replaced by monthly fees with the Pay-As-You-Go option.
• Just scaling our service-bound resources (horizontally mostly, but vertically as
well) between on-premise and cloud is just one part of dynamic resource provi-
sioning/allocation. A similar mechanism should exist inside the cloud and
between clouds, if one cloud is not enough. This flexible provisioning and ability
to maintain redundant implementations considerably improves HA.
In addition to runtime dynamic resources provisioning and (re)allocation, we expect the
following:
• Test/development environments' provisioning are always a headache for non-IT
companies (actually, for IT as well). We need at least three of them per Prod,
where the last one, Operation Readiness Test, must be equal to production. If
provided too early, they will waste resources, and if too late, they will affect the
quality of our tests. We must have the ability to choose what configuration we
want to install (better, and in a friendly way) and access the resources automatic-
ally in a matter of minutes (in complex cases, a couple of hours).
• Resource provisioning should be rapid, and relocation (local2cloud or
cloud2cloud) should be as simple (to us) as copying a file. This service relocation
must be non-disruptive, which means that service consumers should not notice
the relocation of production resources.
Talking about service and service runtime environment, we would like to stress the fact
that we are not discussing the reallocation of a synchronous *.jar service file from one
Search WWH ::




Custom Search