Virtualization vs. Cloud Computing (II): more technological differences

First of all, it is quite important to remember that this post is referred to the scope and context defined in my last post (titled “Virtualization vs Cloud Computing (I): what are we going to compare?”), where I defined Virtualization and Cloud Computing concepts used for this comparison; those definition could be others, of course, but then the conclusions will be others too, so due to its importance let me summarize them in the following points (if you need a more detailed explanation, please read my previous post):

• By “Virtualization” we are going to refer ONLY to the “Hardware virtualization”, i.e. the creation of a virtual machine (VM) that acts like a real computer with an operating system (quoted from wikipedia)
• In Cloud Computing we´ll use the most clear and currently accepted Definition: the NIST one that says: “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction” and consequently,  disregarding the Service Model (IaaS, PaaS or Saas) and the Deployment Model (Private, Community, Public or Hybrid), states 5 Essential Characteristics for a CloudComputing service:
  • On-demand self-service,
  • Broad network access,
  • Resource pooling (multi-tenant),
  • Rapid elasticity,
  • Measured service.
• Besides, to make the comparison possible we must focus ONLY in the Infrastructure as a Service (IaaS) and in this discussion we forget other cloud service models as PaaS and SaaS.
• Finally, as in the virtualization concept, to easy the comparison we ONLY speak about the “compute resource” inside the IaaS Cloud Computing concept.

 

In this context,  in the last post we saw how Virtualization is an enabling technology for Cloud, one of the building blocks used for Cloud Computing. Nevertheless, let me advance that at the end of this post will review and nuance this point because of both the recently arisen customer’s needs and the technological innovations.

 

Referring to the other essential characteristics defined by NIST for Cloud Computing, for example, “pure” Virtualization” itself does not provide the customer a self-service layer and without that layer you cannot deliver Compute as a Service, i.e. a self-serving model however is not an essential component of virtualization, as it is in cloud computing. The next picture (quadrant) shows, on one hand, the evolution of IT technology in the last 3 decades (roughly) starting in the top-left corner (maverick niche IT) when any company department provisioned itself any IT infrastructure it wanted (according to its selves criteria), to when the provision was controlled and the management was unified but any department had its own machines (bottom-left corner or “managed IT infrastructures”), to last decade when the IT were provisioned and managed by IT department and shared by all or several departments (using virtualization), to the current times of Cloud Computing; and on the other hand, it also shows how self-service is one of the differentiation between Virtualization and Cloud computing (Note: I’ve used this quadrant other times since I saw in some publication, but I cannot remember where, so I apologize but I cannot refer it; besides I recreate it, so something could be changed).

 

Break: In the above picture doesn’t appear the older times (lasting more than a decade) of mainframes, a realm where IBM was the king. In such environments the provision and management was controlled, and the infrastructures were shared, so it would be placed the same corner that virtualization, i.e. in the bottom right corner.  The transition from mainframes to the free-riders’ ”maverick niche IT” was due to several factors but, in my opinion, two were more significant: on one hand, the commercial labor of IBM competitors, as Digital, that offer to universities very low cost computers (as the VAX and PDP series of Digital) achieving that the computer sciences graduates wanted similar computers in his hew jobs, and on the other hand a disrupting technology as the emerging of PC (by IBM); both of them, among others fostered and fueled del “selfie” spirit (please, let me use this modern buzzword with a different meaning: the wish to be self-sufficient, as natural in human being) that boosts the gradual transition to the self-service dedicated infrastructures (i.e. from the bottom-right corner to the top-left one); and a last thought about this point: certainly Internet rising as well communications and other enterprise needs also contributed to this transition but, in my opinion, once the movement was already started.

 

Coming back to the self-service essential characteristic, some Virtualization Management Environments  include a self-serving component (but it’s not mandatory) as well as features to allow the customer to know how much usage it has made (metered services) and the resources are elastically provisioned and released (rapid elasticity). Once again, all this features are mandatory in the Cloud but they are optional in a “Virtualization Management Environments” since they are not intrinsic in the virtualization technology. In fact, a “Virtualization Management Environments” will become a Cloud Computing Environment if it meets all the 5 NIST essential characteristics, an evolution that, for example, VMware has been following these years … Given that in the enterprise market, VMware’s (ESX hypervisor and vSphere) virtualization management environment is king, let me analyze little deeper this last subject as an good example of this point:

• Although I’m a supporter of Open Source and therefore of OpenStack when speaking about Cloud, it must be recognized that VMware has a powerful suite of virtualization and cloud products. Concerning to this point of discussion, right now two products must be discerned: “vCenter” and “vCloud Director”:
• On one hand, vCenter is what manages your vSphere virtual infrastructure hosts, virtual machines, and virtual resources (CPU, memory, storage, and network), i.e. a pure virtualization management environment.
• On the other hand, vCloud Director (vCD) is at a higher level in the cloud infrastructure. It´s a software solution providing the interface, automation, and management feature set to allow enterprise and service providers to supply vSphere resources as a Web-based service, i.e. it takes advantages of vCenter to orchestrate the provisioning of Cloud resources by enabling self-service access to compute infrastructure through the abstraction of virtualized resources. In other words, it abstracts the virtualized resources to enable users to gain self-service access to them through a services catalogue. i.e. it provides the self-service portal that accepts user requests and translates them into tasks in the vSphere environment via the vCenter.
• In summary, vCenter is required to administer your virtual infrastructure but it doesn’t create a cloud. The first piece required to create your cloud is vCloud Director. vCloud Director will talk to your vCenter server/servers but certain tasks will have to be done first in vCenter, such as creating a HA/DRS cluster, configuring the distributed virtual switch, adding hosts, etc.
• Note: By the way, now that VMware has announced that it splits vCloud Director into vCenter and vCloud Automation Center (a product that is derived from VMware’s DynamicOps acquisition) and it also seems that capabilities like multi-tenancy management and self-provisioning would be pushed into vCloud Automation Center (vCAC), while constructs like the Virtual Data Center would fall into vCenter, everyone that relly wants a Cloud environment with VMware it shall to buy (or migrate) vCAC, a heavyweight software, much like an IT service management product, requiring deep integration with IT business processes and an ERP-like implementation scenario, since pure vCenter will keep lacking the cloud-like self-service feature.

 

However, THERE ARE STILL MORE DIFFERENCES because according to NIST (and it’s intrinsic to the Cloud Definition) the “Resource pooling (multi-tenant)” property implies “a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter)”. However, as you know, most of the “Virtualization Management Platform” let you choose in what physical machine your VM is going to run, o let you move your VM from a physical machine to another exact physical machine (chosen by the customer). In fact, some customers want (even need) such features, and that is one of the points that let know if the customer really wants or needs and Virtualization Environment or a real Cloud Computing Environment (for example, If you listen to your customer that he wants to move by himself its VM from one physical machine to another, he’s not specifying a Cloud environment, but a Virtualization Management Environment). This no location knowledge is also applied a other features as High Availability (HA), Fault Tolerance (FT) and so on: for example, in a Cloud Management Environment you can specify as much as a different “infrastructure area” (for example a different DataCentre, or something like) for locating the stand-by VM, however in a pure “Virtualization Management Environment” you’re able to choose the specific host (physical machine).

 

Moreover, and associated with the previous idea of no location knowledge, Cloud is intrinsically thought to massive scale out, i.e. without limit, and for physically (possibly in different places) distributed resources, but much of virtualization management environments are intended to manage a number reasonable (maybe big, but not enormous) of physical machines (hosts) and in most cases in the same emplacement.

 

Finally, as advanced at the beginning of this post, new customers needs are emerging to deploy applications on physical servers, instead of  virtual servers, but keeping all the cloud model advantages (and essential characteristics): that’s the case, for example, when your application requires physical servers, or your production environment is too performance sensitive to run in VMs. Actually you don’t need to have a virtualized environment to be considered a cloud environment: your “virtual” instance might be a “container” which is not virtualized but running on bare metal (just sharing it with other containers) or even running directly and using completely the bare metal: “containers”, as aforesaid, are considered by some authors as sort of virtualization, so let me expose an example of the second case: OpenStack is currently developing the new “Iron” module that it’ll provide “Baremetal as-a-Service”, so  it’ll be possible to use the same API and the same pipeline to build, test, and deploy applications on both virtual and physical machines. Therefore, cloud technology is starting to use other technologies away from pure paravirtualized environments.

 

So far, as consequence we’ve seen in the previous post and in the current one, we can conclude that:

• Virtualization is an enabling technology for Cloud Computing, one of the building blocks used “generally” for building Cloud Computing solution (“generally” but not always, because nowadays Cloud is starting to use other technologies away from pure virtualized environments to offer  “Baremetal as a Services” …)
• The services provided by “Cloud Computing Management Environment” and by a “Virtualization Management Environment” ARE QUITE DIFFERENT IN HOW THE SERVICES ARE PROVIDED:
  • the self service characteristic is mandatory in Cloud, and optional in a virtualization environment.
  • the location independence features (in the sense of no location knowledge) is intrinsically essential in Cloud, however most of virtualization environment lets know or operate with the location of VM.
  • massive scale out is also inherent to Cloud Environments, but much Virtualization Management Environment are only not prepared for manage “enormous” quantities of machines distributed in different emplacements.

 

Next post, I finalize this comparison focusing in a couple of technological differences:

• The first one, “measured services”, in some way arise from the different business models that both, Virtualization and Cloud Computing, were INITIALLY intended for, and that will let me to compare those business models too.
• For the second one, we will widen lightly the comparison scope to include (as usual) any computing related resources, (not only but also storage, and communications resources), and then we’ll analyze new differences: for example communications related Services (routing, firewalls, load balancing, etc.) are seldom (or never) offered as a Service in Virtualized Management Environments (in a self-service way and where you can self-define your internal communications layout and structure, and so on).

 

Note: Please, let me add that Tissat (the company I’m working for) is offering real IaaS Cloud Services as well more traditional DataCenter services (as housing, hosting, virtualized hosting, DRP, and so on) based on its Data Centers Federation (that includes Walhalla, a DC certified as Tier IV by The Uptime Institute) and using different product and solutions (currently VmWare, OpenStack, and so on) and most of ideas of this post series are extracted from that experience.