Cloud Application Layer Part II.

	Ph. D. Julio Fernandez Vilas
	¿Any comments? jfvilas@gmail.com

One of the strongest arguments to defend cloud computing is its cost model, as we have seen in previous articles. Although performing control on costs is important, to move from a model based on CAPEX and OPEX to a pay per use model (CAPEX = 0, there is no CAPEX and OPEX is lineal), it remains especially important being able to be tied to a provider.

It is vital to be able to change provider without cost or at least paying the minimum possible cost, since the prices offered by vendors will probably be subject to revision, which could undermine the competitive advantages of the pay-per-use model.

A change of provider must be performed, typically by modifying configuration files or any kind of helper-class if needed.

Again, it is necessary, when we are talking about integrating cloud services into business applications, to create an intermediate layer that isolates applications from using the cloud services they use.

We are talking again about the Cloud Access Layer, which in this case is embodied in a software layer, typically a connector or adapter. This piece of software is what (inside our cloud computing stack) we call the cloud access point.

Develop or adapt applications that accesses the cloud via access points in the future ensures the ease of changing a provider.

This ease of switching providers will take advantage of competitive rates for the same service (form different providers), so that the cost of changing the provider is so small that could exploit the slightest variation in the cost of cloud services that we are using.

Now that we have introduced the concept of provider as an important element within the cloud computing stack, we will redesign the stack. This is CCS2.0 (Cloud Computing Stack 2.0).

Cloud Application Layer. Part I.

We can think of the Cloud Access Layer as a "bus", and here we could start thinking about ESB (Enterprise Service Bus), but it is not the case. The ESB is something that works at a higher level of abstraction, ESB runs at business application level.

What is needed to move up and down services from/to the cloud is a standard common interface, based on the use of standards that should include:

1. Grant independence to cloud based applications, so they don’t need to be aware of its own cloud services (which are used to run the business).

2. Change providers without a trauma, i.e., have a common standard API.

3. Go up and down from the cloud as needed.



1. Independence.

It is a basic criterion for application design. In fact, it is not a new paradigm the fact that applications should be developed in response to that independence from the infrastructure on which they run.

40 years ago the concept of operating system to isolate applications from the management of the processor, memory or disk space was coined. More recently, about 20 years ago, the driver concept appeared to isolate the treatment of different devices from the application’s point of view (think for example in the management of printers).

More recently Application Servers arisen to isolate developers from having to deal with problems such as connecting to a database, use a messaging subsystem, or the actual interface with users (typically web browsers).

Well, according to this evolution, applications that use cloud resources should be independent of the cloud resources they access, and that independence must easily allow activities such a change of provider.