Cloud Computing: The key is standardization

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

And suddenly there came a cloud, and many thought: why not to move all may workload to the cloud and I’ll get rid of a management problem and systems infrastructure that has nothing to do with the object of my business?

This is the question that is sure to have made themselves some many CIOs and CEOs over the last 4-5 years. And of course, technology is often not perceived as a competitive advantage, but as a necessary step to "run the business", which has significant costs, and requires expertise that contributes very little to the lines of business.

But what if the technology is a key in my business? And I'm not talking about an IT company in the world, but a company that uses the Internet as a sales channel. Think in Zara, apart from managing 100% of their e-commerce infrastructure, they will shortly open a store in Alibaba to further its Asian customers arrival. Or think in Marks & Spencer (we will come back on this later), the largest UK retailer.

There is a clear trend in the market, especially in the specialized press, to compare cloud computing with "Utility Computing", a concept for a few years now, from the point of view of functionality, is reviving with this new denomination.

The term "utility" is related to everything that revolves around consumption, with a concrete way to consume and pay for what is consumed. It's especially important when it comes to electricity, water, or oil.

When the tagline "computing" is added so the aim is to associate the computer (or IT services in general) to a form to be consumed in the style of water or electricity. The same is happening with cloud computing, and it starts to look like a form of consumption of IT services on a pay per use model.

And it's true. As mentioned in lectures and presentations and all around Internet, one of the most distinguishing characteristics of cloud computing is its “pay per use” model, i.e., lack of investment and exclusively operating costs: no CAPEX and linear OPEX (proportional to consumption, no steps).

And can we compare the use of IT services to the electricity consumption? For me (and this opinion is generally divided) the answer is easy: NO, for several reasons:

1. An IT service is not a “power”, it is not consumed in watts. Why in the 60's and 70 local power plants began to fuse to give rise to the great monsters of the global power with which we live today? Well, it may seem obvious, because they could do it, because all of them sell EXACTLY the same product. The watts are all equal, regardless of vendor, which, as we shall see, does not happen with technology.
2. One of the advantages of the utilities is that we can easily switch providers. For example, if I hired my power from EDF, I can easily switch to Enel, RWS or the dealer concerned, and this facility is due to the simplicity of the product sold by vendors: the watt. For IT services, each vendor is selling a different service offering. Although there are products in the cloud that seems to be consistent (Oracle in the cloud, SQLServer in the cloud, Enterprise DB, Amazon RDS, etc. ...), the reality is that they are only compatible in terms of functionality, i.e. all of them do the same things, the problem is in the implementation, since they are technically different, and one must work differently with them.

In any case, although the utility model does not apply to computers, it does not make the model posed by cloud technology is not usable, obviously.

Let’s go back to the example of electricity. Early last century to mid-century, it was not unusual to find companies that generate their own electricity, especially all industries using motors in their manufacturing processes (anecdotally, cogeneration has returned to the scene a century later). All that disappeared because electricity suppliers were responsible for "assuming" the problem over to heavy industry.

But think for a moment that we have a factory that handles 220V AC motors, DC motors 83V, or 4-phase motors. If we call an electric supplier to provide us power we will find a small problem, which is that the power supply is standardized, and vendors can only offer current two-phase or three-phase, 110V, 220V and 380V. What do I do with my engine 83V powered engine?

Well this problem seems trivial, since the "standardization" is something that has been working globally throughout the second half of the twentieth century (ISO, for example, was established in 1947). Standardization is one of the inhibitors of the adoption of cloud technologies at medium and large global companies.

So far we have referred to standardization as a rule to be applied at the base architecture (hardware, operating system, etc.). But standardization is also a key to the operation. That is, customizing a server is a resource- and time-consuming process that should disappearfrom datacenters. The aim is that the provisioning processes, deprovisioning and operation can be automated (orchestrated, as discussed later), and all these processes may also in turn be standardized. Please remember that is mandatory to apply economies of scale in order change cloud technologies into an attractive technology offer.

That is, little good is to standardize operating systems if the process of deploying applications and services are different for each server that I have in my installation.

BOTTOM LINE
The supply of cloud services, as far as infrastructure is concerned, which, as we shall see, is the most requested service today, and it is limited to only Windows and Linux. That is, entities like BSCH or BBVA with a financial core hosted on several zSeries can only take advantage of the work mode of the cloud for some of their technological base, which in addition will not be the core.

Cloud Application Layer Part III - Up & Down

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

Let's recall now the concepts of public cloud and private cloud, which are easily understandable if we really understand the relationship between the Internet (public) and (private) Intranet. When a company uses the public cloud, and then publishes services internally in the organization using the same technologies, i.e., in a private cloud, the company is acting as both a client consuming cloud services and a provider that offers services to its own iT services.

This is important when assessing the costs, as it will allow the consumption billed individually, affecting a business unit costs associated with the services they use.

Moreover, we must consider that the company is a living entity, constantly changing, and the fact of offering services from a cloud, whether private or public, is a key factor in making changes to services. That is, we endow the company a considerable amount of flexibility, since domestic service consumers do not know whether such services are being offered from inside or outside the organization.

In a last step in the adoption process of cloud technologies it is very important to have bothered to make a good design of services consumed in the form of a private cloud. If the design is good, the migration to a cloud service can be done easily. It is important to focus on a key concept for this migration to the cloud be done easily: STANDARDIZATION.

We need to design our private cloud services so that they are compatible with the public cloud. When we talk about compatibility or standardization, it is important to have a clear understanding of the layer of cloud technology we are focusing. For example, if we are thinking about IaaS, we have to make sure we use only x86 architectures, we are restricted to Windows and Linux, standard virtualization technologies, iSCSI, etc.

If you are thinking in SaaS (cloud email, for example), which is standardized is functionality. That is, we can migrate our on-premises platform (Exchange, Lotus, etc.) to an email platform in the cloud (Gmail, Outlook.com, etc. ..), provided that it assures me that the functionality that I will get on the new platform is at least the same as I have on the current platform. We should note that in the SaaS projects we will always find a CAPEX amount in the project corresponding to migration.

And all this in terms of going up to the cloud. And what about going down from the cloud? If we have taken into account everything said so far, the download process (or even transfer to another provider) is exactly the same. Remember that we are talking about going up to cloud from a starting point that assumes we are already working on private cloud.

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).