Cloud Computing: The 3 layer model

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

So far everything that relates to the architecture of cloud-based technology model. With regard to the implementation model or working model, we distinguish at least 3 entities, although each of them may be subdivided depending on the business needs:

a)        Infrastructure Provider is the entity that provides services in the cloud.

b)        Service Provider is the entity that consumes the services to be offered to a third party.

c)         Client Service is the final consumer.

This, with a real example would look something like:

According to the Gartner report on the current state of cloud technologies (http://www.gartner.com/document/2515316, access rights maybe required), today we can separate it into 4 modes according to "how" the customer manages the infrastructure used in the cloud:

a)        IaaS+ Middleware. In this mode the client (subscriber) manages the infrastructure and is responsible for deploying their own middleware (or use pre-built middleware that facilitates the service provider models).

b)        IaaS Cloud-Enabled. For the customer remains IaaS mode, but the provider handles the scaling part (elasticity platform).

c)         PaaS Cloud-Based. This is where the great change in the way we manage. In client mode only PaaS handles the functionality of the platform, and is the provider who manages the hardware and software infrastructure.

d)        PaaS Cloud-Native. The operation mode is the same as in the previous model, with the addition that the middleware layer is designed and configured to work in cloud mode.

In the figure below we can see the different "grade of management" that must perform the subscriber of different cloud services based on the hired mode.

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.

Cloud Applications Part II (aka Cloud Computing Definition #3)

In previous post we’ve coined the first cloud computing definition. Remember it, please: “A cloud application is a computer application developed using a standard computer language that can be run on different platforms. One or more resources used by a cloud application are networked resources accessible via Internet. In addition, resources used by cloud applications are exposed via standard interfaces and protocols and should be interchangeable.” Now, let’s continue talking about networked resources.

Networked resources
This is one of the main differentiators between a “classic” computer application and a cloud application. Cloud applications use resources that can be reached through Internet. These resources are offered by different companies at different prices and, of course, different service levels.

Please, at this moment, think of a networked resource as something similar to a web service but with a lower abstraction level.

When someone decides to build a cloud application, one of the first steps in the development he must perform is to decide which of the resources needed for building the application will be bought from an external company and which of them will be used as part of an in-house strategy. I’ll explain it.

Suppose you are developing a web application to support a student registry in a XXI century school, where all students’ works and exams are digitalized and stored as part of its academic files. Now just think of a simple CRUD application (Create, Read, Update and Delete). The following list could be a typical shopping list for that kind of application:

• Servers to host and execute web application.
• Database storage for storing records that will be created and accessed online from the application code.
• Plain online storage for storing pictures related to students. This storage must be online, since web pages include pictures of the “objects” the application manages. Since we plan to have lots of digitalized data, we discard the use of blobs.
• Plain offline storage for backup and restore purposes. Let’s assume a weekly backup of the whole database and filesystem-like storage (digitalized exams and works).

You can run the application in your server farm at your datacenter or conversely you can sign a contract with an ASP (Application Service Provider) to host your web application (this could be considered a cloud service).

What to do with the database? You can use your in-house relational database or, thinking about cloud computing, you can use relational cloud storage to store your data.

The same decision must be taken for the plain storage for storing digitalized info from students and weekly backups.

Anyway, all the services you buy from a third-party provider (instead of using your datacenter resources) must have a very clear contract and a corresponding SLA including minimum service levels offered and penalization for running under that minimum.

Please keep in mind the student registry sample, since in next posts I will refer to it.

The relational database, the online storage, the offline storage is what I call networked resources, since the can be accessed from the application wherever they are stored. Please note that we don’t care about SAN, NAS or SQL. For the moment, we are caring only about having a resource and accessing, we are assuming we have a standard platform-independent way of accessing and using precious mentioned networking resources.

Note: We will come back to this point (deciding between in-house or cloud strategy) in future posts when we will expand EMC’s “private cloud” definition from infrastructure level to application level.

Standard Interfaces and Protocols
Although it has been mentioned before, I wish to remind you that the most commonly used mechanisms for performing remote invocation standard uniquely inside each native platform (DCOM on Windows, remoting on .net or EJB on Java). The only real standard platform-independent mechanism that can be used in remote invocation is Web Services, which means SOAP over HTTP. So, it is clear that standard platform-independent mechanisms (like SOAP or REST) is the only recommended way for accessing networked resources.

Interchangeable
Yes, I sad interchangeable, but, at this moment, it is only a desire, or just a dream. We will go back to this complex issue in the future, after discussing Amazon, Windows, Google and others’ cloud strategy.

Summary
Finally, I wish to publish my first Cloud Application Stack.