In my last blog I talked a little about how the symbol of a cloud is used in system modeling sessions. For diagrams of N-tier architectures, the cloud typically symbolizes the network, and in many cases, the Internet. Similarly, clouds get drawn to represent transactional resources that we interact with. Invariably our diagrammed clouds represent some service or resources that we don't want or need to know the details about. But someone knows the details behind the cloud on the diagram, and for that matter, someone manages that cloud. With the quickly forming practices around cloud computing, that someone might be you. So, will you manage the cloud or will the cloud manage you?
We draw the cloud as a single resource, like the picture above right. That's how it 
should appear to our users, a single resource, a single entity. However, those managing the cloud know that it's really a group of N resources providing N virtualized services to our users. Cloud computing gets its power from the easy availability of redundant servers (hardware-based or VM-based), and the virtualization of the applications provisioned to them. Easy availability of resources however does not equate to easy manageability of those resources or the automatic virtualization of the applications that run across them. If we have to administer each resource in a cloud individually, like the picture on the left, then I would argue that our cloud is not very cloud-like at all.
Just as the cloud appears as a single, useable resource to our users, likewise a true cloud should appear to administrators as a single, manageable resource (like the picture below right). Let's look at one example of what I mean by this. If an administrator needs to deploy a new version of an application, she should not have to install and configure it on each server in the cloud. Instead, she should simply deploy the application to the cloud itself, and let the cloud take care of distributing, installing and life cycling the application without overall application downtime.
To achieve this vision, we need some cloud administration requirements:
- Our cloud should be manageable as a single entity all the way down to the application level rather than server by server, resource by resource, application by application
- We should be able to install cloud-based applications, support libraries, and even the cloud platform software itself, in an automated, version-controlled manner across the cloud, without downtime.
- The cloud should enable application configuration across the cloud without downtime
- Guided by policy and rules, the cloud should be self-organizing and self-healing to minimize or reduce any need for administrative intervention
Such a cloud environment would allow cloud-based applications to scale linearly and manageably by allowing an administrator to simply add new resources, while the cloud manages the upkeep and care of those resources. Likewise, with no need for administrative action, such a cloud environment can automatically provide processing reliability, high availability, and robustness through self-healing, and transactional recovery.
Unfortunately, many cloud environments do not provide this level of, dare-we-say-it, virtualization. This should be a cause of concern. Consider the use of virtual machines (VM) in the enterprise today. 
Concerns over "VM sprawl" continue to rise. Certainly virtualization creates a way to wrap up operating systems (OS), platform software, and applications into a neat bundle. This level of virtualization gets you ease of provisioning and deployment. VM images can be spun up with ease on a server, consolidating what had been ten servers into one server running ten virtual machines. However, as the phrase "VM sprawl" denotes, ease of deployment does not make VMs, nor the applications running on them, easily manageable. What if I just need to change a single application setting? Must the VM image change? Indeed, many IT shops treat the VM image as a Quality Controlled item, and changing the image triggers testing requirements, which can be an expensive and time consuming process. All for a simple application configuration change. Or must I go to each VM in turn, and configure the application?
Wouldn't it be better if I could virtually administer across all of the application layers on all of my VMs without having to manipulate the VM images? VM sprawl exists because this higher-level virtualization layer is missing. Now expand this beyond VM management to the cloud. If cloud computing does not extend virtualization up to the administrative and application layers as described above, there is the risk that the very promise of cloud computing will be undermined.
