The cloud refers specifically to the lifetime use of the cloud icon in a network card to indicate an external or undefined resource. The origin of the term refers to placing components of your network infrastructure outside of your own environment ... and, thus, in one of the clouds on your network diagrams. Today, the term has grown to encompass many different ideas and has been heavily polluted by competing definitions.
IaaS / PaaS / SaaS / LBaaS / etc etc.
These are all services. Very consistent with the idea of ​​accessing the components of your infrastructure ... as a service that exists in the cloud on network architecture diagrams.
However, each of these aaS solutions has different methodologies in how they achieve their goals. Some of them could not meet the classic term "cloud". For example, some aaS components may not be external to your network architecture. Things like the "private cloud" may appear here.
Private cloud is a terrible term. This is an oxymoron. Since it is not external to your environment, it is not a cloud in your diagram. But since people have desecrated the meaning of the term “cloud” to almost incoherence, we are stuck with this term, at least for now. So bear with me when I say "private cloud". It is not cloudy in any classical sense. This is what in English we will call "wrong."
Now it’s important not to confuse aaS cloud solutions with resilient design principles that a large cloud provider such as amazon or rackspace will use in aaS solutions.
The principle of resilient construction will emphasize horizontally scalable common infrastructure. The easiest way to describe this ideology is the example of cattle and puppies. We used to look at server resources, as we looked at puppies. We called them. We treated them well. We taught them tricks. And, if they fell ill, we carried them to health. We did everything we could to make these servers happy and working well. We grew them vertically. We have optimized them. More ram, processor, development resources ... etc. In a resilient model, we view our resources as cattle. They have serial numbers. We put minimal effort into teaching them. They are as uniform as possible. Any optimization that occurs arises during configuration management and is shared between them as stand-alone solutions. If they fall ill, we shoot in the head and replace it with another. The advantage of this design paradigm is that if you start shooting at your server racks with a shotgun, the chances are that the whole environment will compensate. Of course, this level of fault tolerance is easier to describe in theory than is necessary in practice.
Now, how virtualization is connected with the cloud. Actually there is no actual REQUIRED relationship. The cloud should have nothing to do with virtualization. You may have a service-oriented resource outside of your environment that you rely on and does not use virtualization. But most of the "aaS" solutions that are supported there by virtualization technologies. They do not have to be at all, but because of the general likelihood that they will be virtualized, these two conditions for many purposes are married together in the minds of the uninitiated.
Re OpenStack and private cloud.
Regardless of whether OpenStack is right for you, this is a very personal decision. And it depends on many things. Running infrastructure can be very expensive. More importantly, it can be very difficult to do well. For a small business or organization, deploying your own IaaS infrastructure really probably doesn’t make sense if someone who has economies of scale can meet your needs. That companies like Amazon fill the gap.
For some organizations using the IaaS solution in their own environment, even when they are potentially or actively served by amazon or rackspace offerings, it might make sense. Some people are big enough and work enough. OTHER infrastructures that host their own resilient applications are financially acceptable. There are other reasons besides a strict lower limit. Many large organizations face political constraints, such as HIPAA, FISMA, or Sarbanes Oxley. Sometimes, satisfying these policy requirements, as well as any of their own requirements for domestic policy, you need to pay a little more.
There are other reasons to go beyond the general offerings of Amazon or Rackspace. Imagine if you want jenkins to be provided as an automated build and test environment, and you want heterogeneous hypervisors or physical nodes to automatically deploy and test compiled software. OpenStack will probably handle this. And if he can't deal specifically with what you mean, it's open source. You can DO it to process what you need.
There are a million reasons to use OpenStack, or not to use it. Ultimately, this is a very personal decision for any person or company. And one that requires significant research. But there are scenarios in which both are great solutions.
When we created nova (an OpenStack ec2 style computing component) at NASA, we were supposedly focused on providing HPC resources or a line of business resources in an elastic way. Amazon ultimately created its own HPC. And even now it is working to overcome the obstacles to compliance with FISMA policy. But there will always be times when your specialization needs will make general market offers less profitable. However, besides technical reasons, competing with Amazon is another important reason. And this is to promote OPEN standards in this new technical field.
Technology development is very similar to organic tree growth. It starts with a bud, which may turn into a leaf. Any new technology arises as a small thing that needs a lot of resources for growth. Not all of these technologies survive. But some do. And those who need money and effort to do this at an insatiable rate. However, as these technologies grow, some of them become industries. Some even become chests. To have a chest from which a million other technologies develop even more industries, open standards are required, controlled by a responsible community. The government and many organizations such as IBM recognize this, and one of the main reasons OpenStack has grown so fast. This is also why BSD and then Linux. The potential for resilient design techniques to change the landscape of technology is exceptional. And in order for the beginning technology to become a branch today, from which many new technologies will emerge tomorrow, we will need strong open standards to make our backbone technologies healthy.