Virtualization Sandbox Vs Cloud Sandbox (from an end-user perspective)

Nov 15, 2010 · 9 min read ·

What is cloud? Good question. You can put down a list of things that relates to cloud. I tried to do this in a previous post. But I've thought recently that that list (alone) doesn't really cut it.

After having worked for a number of months all day long on this "cloud thing" I came to the conclusion that you need to explain what cloud is in a substantial different manner. In order to fully understand what cloud is, its principles and its end-goals, one needs to take a step back -maybe two steps back- and think about it from a philosophical perspective. I have tried to do this in my Cloud 101 session at VMworld in San Francisco where I spent a large chunk of my time discussing cloud from various (philosophical) perspective. They were:

the "Contract"
the "Sandbox"
the (transparent) "Choice"

In this post I'd like to focus and share what I discussed in the Sandbox part of the presentation because it's the technology foundation for many cloud-related discussions. As you may have depicted at this point, I am focusing on Infrastrcuture as a Service (IaaS) type of clouds.

Put yourself in the shoes of your favorite vSphere administrator and you'll notice that you have the whole infrastructure at your disposal:

You have pretty much everything available in a single dashboard: Datastores, Resource Pools, Distributed Switches, PortGroups, Templates. Advanced vSphere users may even have used vShield Zones which provides firewalling capabilities in a native virtual environment. In essence you have the infrastructure at your fingertips.

Now, if you think about the relationship between the vSphere administrator and the end-user, we can note that most of this flexibility is only available to the former. What usually happens in fact, in most Enterprise virtualization deployments the end-user (typically a LOB) asks IT a virtual machine for consumption. This process may be triggered via chat, over the phone, via e-mail or via formal life-cycle tools depending on the maturity of the Enterprise deployment. The process usually is:

End-user: I need a VM with 1 CPU, 4GB of memory, 60GB of disk, connected to the corporate network (and optionally with firewall configured to only allow port 443 in).

IT: Ok here it is, 1.2.3.4 is the IP address of the VM, you can connect directly via RDP / SSH.

Long story short what happened here is that the vSphere administrator have leveraged the great deal of flexibility that vSphere allows in order to create such a "virtualization sandbox" to give to the end-user. This may take sometimes between a few weeks or a few hours depending again on the different processes that every Enterprise IT uses to fulfill these requests.

The end-user has been exposed to none of the flexibilities that have been introduced into IT by virtualization technologies. The software stack they reach via RDP / SSH could be running in a VM or on a physical dedicated server, they wouldn't know. The only thing they are exposed (if they are lucky) is time-to-deployment. Since it's easier/faster for IT to create a VM than installing a physical server, the end-user should be able to appreciate that. However I have noted that many times this is not enough. This may be due to overkill processes at the IT level to create a VM (processes typically inherited by the legacy physical deployments) or it could be due to end-users always looking for a faster way to deploy their platforms. Not to mention that any change outside of the perimeter of the "virtualization sandbox" still needs to be done by IT using vSphere tools: change the number of CPUs, change amount of memory, add a new disk, change a firewall configuration, the list goes on. And this may require additional time (again, depending on the processes in place). In addition to this, if I need a brand new VM, I need to restart the process from scratch opening a new request ticket to IT.

Wouldn't it make sense if the IT admin could create a much richer sandbox to hang over to my end-user? A sandbox that doesn't frame just the software stack that that the IT has deployed and has given to the end-user, but rather a sandbox that can provide, at a smaller scale, all the capabilities and flexibilities IT is enjoying working on the vSphere console? All this done in a way that this rich and flexible, the sandbox is secured, controlled and can't cause any damage to my whole infrastructure nor to any other tenant sharing it? That's a key aspect of cloud. Most people think, when talking about cloud, of "self-service" as "a web portal". Wrong! The web portal is just one of the many tools you can use to access the infrastructure in "self-service" mode. We'll explore this later. This picture is supposed to visualize what this "cloud sandbox" is:

If you can just take away a single concept from this post here it is: (IaaS) cloud is all about allowing end-users to experience the very same richness and flexibility virtualization administrators have enjoyed for the last 10 years! It's not about deploying a virtual machine via a web portal. It's about giving the end-user a certain amount of CPU, Memory, Storage resources coupled with the possibilities of creating their own catalogs of software stacks, role based access and network policies. It's all about giving them a "virtual datacenter" to play with Vs giving them a VM.

And this is when vCloud Director started to make sense to me. I have to admit I have approached the product in the wrong way the first time I have been exposed to it. I was looking at it as a web portal to vCenter. Many people (unfortunately) look at it this way too. The fact is that, in order to implement this cloud sandbox vision, you need new constructs and a level of abstraction of the infrastructure that goes beyond traditional virtualization objects. The picture below should visualize those objects and the "journey" to a cloud layout.

At the bottom you find all the traditional vSphere objects (Datastores, Resource Pools, Distributed Switches, PortGroups etc). On the left hand side there are the Provider vDCs: they are a group of homogenous resources that provides a sort of SLA (think a Gold Provider vDC with HA-enabled RPs + Fibre Channel Datastores and a Silver Provider vDC with non-HA-enabled RPs + SATA Datastores). On the right hand side there are the Organizations; these are the consumers of the cloud resources. This example is geared towards public cloud deployments where a service provider sells resources to Enterprise customers (think Fiat, Nissan, Mercedes). In a private cloud deployment the IT department may be selling resources to internal organizations (think Sales, Marketing, R&D, etc). Note how each consumer has subscribed to certain class of resources the provider makes available. For example Fiat and Nissan both subscribed to get access to Gold and Silver resources whereas Mercedes only subscribed to get access to Silver resources. You can assign compute capacity based on a number of different subscription models: Pay-As-You-Go, Allocation and Reservation. If you want to deep dive into each of these model read this blog post from Duncan (highly detailed). While cloud is typically associated with the PAYG model, we also hear a lot of our customers wanted to have more predictable access to resources. This is of paramount importance, in some circumstances, where customers want to federate their local vSphere / vCloud setups and want to treat this cloud sandbox as an extension to their actual datacenter (with certain SLAs).

Now that we have assigned compute capacity to these organizations, we attach these organizations to the external network via vShield Edge. The magic here is that, by giving full control of the Edge device to the tenant, we enable the tenant to have full control over its networking configuration. If you want to know more about how networking works refer to my previous post vCloud Director Networking for Dummies. Highly recommended since networking is a key component of vCloud Director.

Note also that, within the organization, we have the possibility to create a "local catalog". If you want to know more about how catalogs work in the cloud refer to my previous post vCloud Director: Catalog Experiments.

Last but not least there is a RBAC (Role Based Access Control) component inside the organization. Remember this is a virtual datacenter and, as in any datacenter, there are different roles for different users. vCloud Director allows for the organization to connect back to a specified LDAP / Active Directory. This is important in public cloud deployments because this is the foundation for hybrid clouds where Mercedes (in the example above) could ask the service provider to point back to the corporate Active Directory at Mercedes. If you want to know more about how this works please refer to my post vCloud Director and Active Directory Backed Authentication.

Long story short this is what the cloud sandbox is and the picture below is just trying to help to visualize the concept.

As you can see the web portal is there, but it's fundamentally just a tool to access the sandbox. What happens within the sandbox, not how you access it, is the magic of cloud. To that point, I believe that API access is even more powerful and interesting.

Now, how is it going to effect the relationship between the IT administrator and the end-user? Remember how end-users used to interact with IT in the "virtualization sandbox" era?

1) End-user: I need a VM with 1 CPU, 4GB of memory, 60GB of disk, connected to the corporate network and with firewall configured to only allow port 443 in.

2) IT: Ok here it is, 1.2.3.4 is the IP address of the VM, you can connect directly via RDP / SSH.

3) GOTO 1 (for subsequent VMs that may be required)

In the "cloud sandbox" era the relationship would look more like:

1) End-user: I want to allocate/reserve 10Ghz of resources, 512 of memory, 5 TB of Storage, a dedicated 10.0.0.0/24 NATted subnet and I want 8 public (corporate) IP addresses dedicated

2) IT: Ok here it is, cloud.corportation.com/YourOrg is the FQDN to connect to your resources.

In this example I have used an allocation/reservation subscription model. In a PAYG model (think the model Amazon uses) I wouldn't call out any number. I'd be using resources on a need basis (if they are available, with no upfront commitment).

As you can see there is no step #3 here (i.e. go back to IT to request another VM if you need it). As always, a picture is worth 1,000 words (IT in red, end-user in blue):

Less work for IT (provider), more flexibility for the end-users (consumers). This is the magic of the (IaaS) cloud. In my opinion of course.

Massimo.