Theory, facts and paradigms, or why the cloud and virtualization are not the same but for the API

I had a conversation recently with a very interesting colleague about "traditional" virtualization and cloud. Although we almost agreed on everything, we were recording a webminar, we had severe differences on our points of view, starting with the fact that "traditional" was not a word he liked... he was from another provider.

In science it is necessary to distinguish between facts and theories, although that distinction can not be completely precise. They act as poles of an activity that crystallize in groups relatively autonomous.

Theories are systems of interpretation and explanation of facts that, once discovered and constituted, that is to say, circumscribed by the theory, seem to be independent of the facts.  That is why we can still talk about the Bohr atom and also why many economic books about theories that are known to be false.

On the other hand, we need to take into account that the theory that acts directly to explain the facts comes from the macro-orientation methodological known as paradigm, that only refers to the facts through the theory, whom acts as middle range hypothesis.
Let's say that all of this works together, so scientists can never do science without taking into consideration, actively or not, those paradigms that are active at the moment, and thus being a reflection of their society.

So the question should be whether the cloud is a paradigm or a theory....

And I would say is a paradigm... the discussion we were having was because the cloud is a completely new way of looking at the facts (virtualization). So although you can explain facts with the old paradigm - has anybody read how hard was for Copernicus to demonstrate that all the other were wrong and their models too complex? -,  the reasons to implement a cloud are not in the old ways of thinking... Even if they somehow look almost right, like being the center of the universe once appeared "clearly" to all.

The definition of the cloud by NIST is here, and refer to five essential characteristics:
Reference: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

• On demand self-service
• Broad network access
• Resource pooling
• Rapid elasticity
• Measured service

All of them can be met by a system like CloudForms  / ManageIQ, or some other alternative tools in the market, but we can not hide that in order to fully get the power of the cloud there are other things that need to be changed, well beyond the software-defined-everything theory.  The first step into the cloud is economic, not technical, but the next one will be technical.

 

Everything has to be optimized for the cloud, starting from the applications (what about DevOps/CI/CD?), that has to be prepared to be executed in any resource, grow elastically and quickly, adapt themselves to the customer, provide the information needed so decisions can be taken. The network has to be prepared too for the new paradigm, although some technologies seems to cover somehow the new and the old paradigm, virtualizing the network, although it is more than virtual networks, is network as a service what we need, and of course all that elements that a cloud management platform or a cloud broken can deliver today.

 

Let's not confuse the path with the objective, because some times, like with the cloud, they are defined together. This is a continuous effort, so start your cloud automating your environment now, evolve your network to a fully open one, change your applications so they are cloud-ready, make them scalable, start providing the information needed by management, educate your users, and don't try to convince your manager that the Earth is flat, because even you can see that the ship goes round it...

Efa [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

Cloud

What is a cloud?

And can we make a cloud out of things that are not cloud-oriented? Short answer: it depends, but mostly the answer is no.

One shoud be aware of the definitions already there for the cloud. In particular, the National Institute of Standards and Technology (NIST), has released a definition of Cloud that is the basis for many other definitions and clarifications worldwide. The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Five characteristics define a cloud:

• On demand self-service. .
• Broad network access.
• Resource pooling.
• Rapid elasticity.
• Measured service

Reference: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
 So the questions remains. Can I get a cloud with whatever infrastructure I have. And I believe the answer is twofold:

• Yes. As you can provide those characteristics with any virtualization, if you can provide Internet access and create and destroy VM automatically, based on measures. That is basically what many traditional virtualization are selling. "Use our virtualization with a management layer and you will get a cloud.
• No. A big no here. A cloud is about applications, not about infrastructure, so creating a management layer on top of your infrastructure will look like a cloud, will behave like a cloud, but won't be a cloud, because your application won't be cloud ready and you won't benefit from the new paradigms.

And that is what I believe is the big wrong thing on cloud. You should be expecting to have improvements because you use a cloud. Those improvements are both in performance, and in TCO for the solution, and in order to get them you need several things, all together:

1.  A management layer. Something that can provide and manage automatically, the generation and access to your workloads, both internally and externally, and provide measures and elasticity.
2. A lifecycle management tool. Because your workloads won't be static, you need to configure, update and depoly content to them.
3. A cloud workload. Elasticity comes with a price, you need to have VM that are ready to join a cluster of other VM, automatically. And that means changes in your development, getting away from HA to cluster-apps. Perhaps a PaaS.
4. An infrastructure that is aligned with the previous points.

The only thing is that you don't need to implement all of them at the same time. Of course you can get a "cloud" on any infrastructure, including physical and/or traditional virtualization, using traditional apps, and you will have most of the features defined by NIST. But you just miss many of the improvements of using a real cloud.

Because the value is in the application! So using a lifecycle management tool, or a management tool, will help you automate your workloads, and thus increase productivity and TCO - we have been doing that for years- but you won't be using a full cloud, because your application won't be there yet. PaaS, SaaS, are already helping you to go that way.

Just change the way you develop and deploy applications, over an infrastructure optimized for cloud, and then you will see the benefit. Increased utilization of hardware, rapid adaptation to the workloads, and thus CI/CD and everything that leads to innovation.

And of course, remember that we are not here to rebuild you datacenter tomorrow, so be prepared to have an hybrid cloud, with different workloads over different infrastructures, for many years.

So, coming back to earth: you really need OpenStack, and containers, and a Cloud Management Platform, and automation, but it is quite possible that the reasons you need them are not those that you are thinking of.

So let's not get confused. A Cloud Management Platform is a great tool, a needed tool, any automation is good, but be careful and know where your limits are.

And test, test, test, do proof of concepts, refactor, and test, test, test. You will need it.