I am confused with virtualization and private cloud computing. What do they serve for? Their purposes? Can they be combined, let say we build virtualized servers on private cloud?
From what I understand, cloud computing embraces the idea of IaaS (infrastructure as a service). In other words, I could start with minimal number of bare metal servers and expand it as requirement needs, and those servers are consolidated into one big machine through divided computing and data storing.
Being said that, can we build virtualization on the private cloud? For example, I might buy like 10 servers (especially servers like in the opencompute project), glue them together as private cloud using openstack, and maybe using Xen or Kvm for creating virtualized servers. Is that possible? Is that ideal?
Please point me to the right Jedi school.
Cloud refers specifically to the age old usage of a cloud icon in a network chart to signify an external or undefined resource. The origins of the term refer to placing components of your network infrastructure outside of your own environment... and thus into one of the clouds on your network diagrams. Today the term has grown to encompass many different ideas and has been largely polluted by competing definitions.
IaaS / PaaS / SaaS / LBaaS / etc etc
These are all services. Very much in line with the idea of accessing components of your infrastructure... as a service that exists in a cloud on your network architecture diagrams.
However, each one of these 'aaS' solutions has different methodologies in the way they achieve their goals. Some of them would fail to meet the classical term of "cloud". For example, some 'aaS' components may not be external to your network architecure. This is where things like 'private cloud' might come into play.
Private cloud is a terrible term. It's an oxymoron. Because it's not external to your environment it's not a cloud on your diagram. But, because people polluted the meaning of the term cloud to near incoherency we're stuck with this term at least for now. So bear with me when I say 'private cloud'. It's not really cloud in any classical sense. It's what in english we'd call a 'misnomer'.
Now it's important not to confuse cloud 'aaS' solutions themselves with the elastic design principles that a major cloud provider such as amazon or rackspace would follow in developing 'aaS' solutions.
An elastic design principle would place an emphasis on a horizontally scalable share nothing infrastructure. The easiest way to describe this ideology is with the cattle versus puppies example. In the past we looked at server resources much as we looked at puppies. We named them. We treated them well. We taught them tricks. And, if they got sick we nursed them back to health. We did everything we could to keep those servers happy and working well. We grew them vertically. We optimized them. More ram, cpu, development resources... etc. In an elastic model we treat our resources as cattle. They have serial numbers. We invest minimal effort in teaching them anything. They are as homogenous as possible. Any optimization that occurs, occurs in configuration management and is shared between all of them as stand alone solutions. If one gets sick, we shoot it in the head and replace it with another from the herd. The benefit in this design paradigm is that if you start shooting into your racks of servers with a shotgun, odds are the entire environment will compensate. Of course, this level of resiliency is easier to describe in theory than it is to achieve in practice.
Now as far as virtualization is related to 'cloud'. There really is no actual NECESSARY relation. Cloud doesn't need to have anything to do with virtualization. You can have a service oriented resource outside of your environment that you rely on that does not make use of virtualization. But, most of the 'aaS' solutions that are out there are supported by virtualization technologies. They totally don't have to be, but due to the general likelihood that they will be virtualization involved the two terms have for many purposes been married together in the minds of the uninitiated.
Re OpenStack and private cloud.
Whether OpenStack is right for you is a very personal decision. And it depends on a great many things. Running infrastructure yourself can be very costly. 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 deals in economies of scale can serve your needs. That's where companies like Amazon fill a gap.
For some organizations running an IaaS solution in their own environment, even when potentially or actively being served by amazon or rackspace offerings, can make sense. Some folks are large enough and running enough OTHER infrastructure that hosting their own elastic applications is financially acceptable. There are other reasons as well aside from strictly the bottom line. Many large organizations face policy restrictions such as HIPAA, FISMA, or Sarbanes Oxley. Sometimes satisfying those policy requirements as well as any of their own internal policy requirements requires paying a little extra.
There's other reasons as well to go beyond the general offerings of Amazon or Rackspace. Imagine if you will that you are providing a jenkins like automatic build and test environment and you want to provide heterogeneous hypervisors or physical nodes to spin up automatically and test compile software. OpenStack can probably handle that. And if it can't handle specifically what you have in mind, it's open source. You can MAKE it handle what you need.
There's a million reasons to use OpenStack, or not use it. Ultimately it's a very personal decision for any person or company. And one that requires considerable research. But there are scenarios in which both are great decisions.
When we were creating nova ( the OpenStack ec2 style compute component ) at NASA, we were ostensibly focused on providing HPC resources or line of business resources in an elastic fashion. Amazon ultimately created an HPC offering of their own. And even now is working to overcome the hurdles of FISMA policy compliance. But there will always be times when your specialization needs will make the generic market offerings less advantageous. However, beyond the technical reasons to compete with Amazon lies another important reason. And that's to foster OPEN standards in this emerging technical area.
Development of technology is very much like the organic growth of a tree. It starts with a bud, that maybe turns into a leaf. Any new technology emerges as a small thing needing lots of resources to grow. Not all of those technologies survive. But some do. And the ones that do need money and effort to do so, at a voracious pace. However, as those technologies grow, some of them become branches. Some even become trunks. To have a trunk that a million other technologies grow off even more branches, open standards controlled by a responsible community are a necessity. The government and many organizations such as IBM recognize this, and that's one of the major reasons OpenStack has grown so quickly. It's also why BSD and then Linux did. The potential for elastic design methods to change the landscape of technology are exceptional. And for the budding technology of today to be the branches from which many more new technologies will arise tomorrow, we will need strong open standards to make our trunk technologies healthy.