Talking from experience, trying to explain “cloud computing” comes with its own challenges. Trying to explain “hybrid cloud computing” is even harder. I always like to think about cloud computing (or hybrid) not as a weapon that marketing departments gave us to cheat people, but rather as a name (or a concept if you will) to describe infrastructure characteristics that we have always been dreaming about – and that happen to be less far away these days. I’d like to introduce the concept of hybrid cloud computing with a slide I have used in my breakout session at VMworld in 2007:
As you may guess, 4 years ago nobody was talking about cloud computing. In fact I have (re-)used the word Grid – which shares a lot of commonality with cloud computing. At that time it was starting to be really easy envisioning a point where you (the end-user) would have been able to instantiate a workload on <any> infrastructure. Quite simply, since your environment is basically a file (VM) running on a specific runtime (the hypervisor), provided you have the same runtime to “execute” that file you can move it around without changes regardless of the location and the type of underlying infrastructure where the runtime is deployed. Was I pitching hybrid cloud? Well I didn’t know but what I know is that a lot of the thinking behind that slide really maps into the discussions I am having today regarding hybrid cloud computing. Essentially the concept of extending your local infrastructure (private cloud) into a shared multi-tenant infrastructure (public cloud). If you want to know more about the presentation I did, click on this link.
Ok, end of nostalgia… let’s fast forward to 2011, because that’s where we are today.
When I joined the VMware cloud team back a year ago I started to look around about what we had in the pipe in terms of cloud technologies roadmap. Certainly vCloud Director was the product I spent most of my time on (from alpha to GA). However I have immediately been intrigued by a little piece of technology that seemed to be pretty promising in my opinion. This product, called vCloud Connector, has been announced today February 8th and it’s part of our broader vCloud Datacenter strategy. Those of you that were in my Cloud 101 presentation at VMworld in San Francisco have seen a demo of an early build of the product. I wanted to include that technology preview in the presentation because I thought this could be one of those “wow” moments that VMware spoiled its users with in the last decade.
You won’t understand vCloud Connector until you get an idea about what VMware has in mind. Or I should say what I think VMware has in mind since this is really a personal interpretation on a personal blog. So let’s get started with my take of what’s going on at VMware and in the industry in general.
A few weeks ago our CTO Steve Herrod posted a very interesting article that touched upon the future relationship between Service Providers (namely Telcos and Outsourcers) and VMware for this decade that just started. That article reminded me of a few slides I showed during my Cloud 101 session at VMworld 2010. I think this one specifically summarizes, in a somewhat practical way, what we are trying to achieve:
What does that mean? The concept associated to the left side of the slide is that VMware has been able, in the last 10 years, to create a layer of abstraction (a runtime and related management tools) between the physical infrastructure and the actual workloads. This infrastructure is typically owned by the end-users in the form of physical servers, storage and networking equipment (CAPEX). In essence the message to the end-users is that, regardless of the underlying hardware being used, we can “homogenize” it and provide a flat space where workloads can move around on-the-fly. This doesn’t necessarily equate to commoditization of that underlying layer. There have been a number of hardware vendors that have been able to stand out of the crowd in terms of exposing their technology uniqueness to the end-users (EMC, Cisco and NetApp are very good examples).
The concept associated to the right side of the slide is somewhat similar with the only difference that we want now to give end-users even more choices. We want them to be able to not only buy new gears when they need to build or expand a datacenter (i.e. CAPEX); we want to give them the opportunity to choose a different method of sourcing that capacity, for example as an on-line service that a Service Provider can deliver (i.e. OPEX). Most would refer to this on-line service as a public IaaS cloud. That’s hybrid cloud to me: the ability to choose dynamically, transparently and on-the-fly whether your application should be deployed internally (CAPEX) or externally (OPEX) based on the application characteristics, SLAs requirements, security policies and so forth.
In order to achieve this vision the traditional constructs available in the virtualization layer wasn’t enough. In order to efficiently deliver on this vision we created a new layer of abstraction and new constructs on top of vSphere that could provide a standard method to access these compute resources. In doing so we can create true multi-tenancy infrastructures and a viable as well as efficient security model to protect the tenants. vSphere alone wasn’t designed to provide out-of-the-box those additional characteristics and that’s where vCloud Director comes into the picture. So what we anticipate in the not so far away future is that end users will deploy this additional tools internally in their datacenter to extract this added-value. At the same time we are working with our Service Provider partners to build similar and compatible infrastructures in order to allow end-users to have a homogenous interface into both CAPEX-sourced as well as OPEX-sourced infrastructures. And this is where the vCloud APIs comes into the picture. I know I have lost you by now, so let me show you another slide of my Cloud 101 presentation that hopefully clarifies this concept:
So how does vCloud Connector fits into all this? Good question. Our ultimate goal, as I said, is to federate public and private clouds into what we call hybrid clouds. While there is a good number (and counting) of Service Providers that can (or will shortly) deliver vCloud based on-line services we realize that there are certainly less private cloud deployments out there than traditional vSphere deployments. The last count, off the top of my mind, was about 200.000 VMware customers (more or less, probably more by now). So what do we do with them? Do we tell them to move to a private cloud first in order to experience this OPEX/CAPEX flexibility? Not a smart decision right? What if they would like to try this flexibility immediately without having to wait to migrate their virtual infrastructure to a true private cloud? This is where vCloud Connector comes into place. In a way you can think at vCloud Connector as the bridge that will allow you to move from virtual infrastructures to clouds in the most transparent way and make this journey an extension of your existing day by day experience. Again this picture from my VMworld presentation may help fix this concept into your head:
vCloud Connector is fundamentally a VMware plug-in that you can install on vCenter and that allows the vSphere GUI to show both traditional vSphere resources and workloads as well resources and workloads in the cloud. No more, no less. Another picture that may clarify this concept further and underline the flexibility and openness of this solution is the following:
The picture above comes from another post I did a few month ago titled vSphere, vCloud and the meaning of being open. I suggest you read it (especially if you are a service provider). As you can see I have put some vCloud Connector hidden nuggets here and there in previous posts. I couldn’t resist talking about it!
From a technology perspective, vCloud Connector is a virtual appliance that you’ll be able to download shortly from the VMware web site that gets deployed on the local vSphere infrastructure. From an operational point of view vCloud Connector gets registered into vCenter as a plug-in so that you can use your vSphere client to view and manage (to some extent) both your vSphere infrastructure(s) as well as your cloud resources. Consider that vCloud Connector allows you to mesh, in a single pane of glass, multiple vCenter based infrastructures as well as resources coming from multiple clouds (regardless whether they are private or public).
Why do I say manage “to some extent” then? Well first of all you need to consider that vCloud Connector consumes vCloud APIs when connecting to vCloud based clouds (either private or public). These APIs are not nearly as rich as the vCenter APIs so there are things that you can’t just do. Changing the vNIC type of a VM is an option for example (among others). This is really by design (vs being a limitation) because one of the idea is that cloud should be all about ease of use and simplicity. That’s the reason why many of the vSphere Administrator type of functionalities are not exposed to the consumers in the cloud.
So one shouldn’t expect to have the very same identical vCenter experience when manipulating a VM or a vApp that is running in the cloud. Another reason for which I said that you can manage these workloads “to some extent” is because vCloud Connector only surfaces a limited set of the vCloud APIs and the vCenter APIs, not all of them. So, for example, editing the properties of a VM is not even possible in vCloud Connector because this functionality has not been (yet) implemented. Keep in mind this is the 1.0 version of the tool.
So what can you do from within the vCloud Connector plug-in interface? Straight from the PM presentation here are the available functionalities:
- Visualize workloads and templates across vSphere and private/public vClouds
- Migrate workloads and templates between vSphere and vClouds
- Perform basic power and deployment operations on workloads and templates
- Access console of vApps in vClouds
This is why I usually refer to the vCC interface as a “single pane of glass” to view workloads (as opposed to manage workloads). In fact, for advanced configuration tasks, you still have to use traditional vCenter tools to manage local workloads running on vSphere and the vCloud Director portal (or any tool that exploits the vCloud APIs) to manage workloads running in the cloud, private or public that is. It is also important to note that vCloud Connector doesn’t add any networking functionality on top of what you can already exploit at the vCloud Director level. The first version of vCloud Connector facilitate the connection to an existing organization network in fenced mode only. I will discuss this in further details in future posts.
And I’d like to close this brief description letting you appreciate the look and feel of the plug-in in the vSphere client interface that most administrators use and (hopefully) love:
If you are interested in getting into a bit of more details about how the product works and what you can do with it, I have just published another post where I show the product in action and a step-by-step guide (with more pictures) on how you can implement it in your datacenter. The post I am referring to is part of a series of other posts I am publishing around the end-user experience of consuming cloud resources and this one specifically is titled My Cloud Consumer Experience – Episode 4: Managing Workloads with vCloud Connector.
In conclusion, this post was supposed to give you an introduction to vCloud Connector and, more importantly, a little bit of exposure to the bigger picture VMware has in mind. It is with this picture in mind that you should look at vCloud Connector and this vision should also give you a hint or two on where we are heading to from a technology roadmap perspective. Let me stress again and be very clear: what you have seen is not our intended hybrid cloud end-state but it’s rather the start of a journey.
As I am closing this post I’d like to also give you a final thought on this piece of software because I think there are two ways to look at this. The first one is that vCloud Connector is nothing more than a nice interface on top of export / import features that are built into both vSphere and vCloud Director. I have demonstrated this in a previous blog post. The second way to look at this plug-in is a bit more philosophical. Try to fast rewind to what IT looked like back 5 years ago and what you were supposed to do in order to move an application running in your datacenter into a “OPEX hosting model” if you wished to do so. Go to the service provider, contract for getting a new (hopefully virtual) server for a number of years, have them provide you with the resources, install the application on the new server, validate the install etc etc. What I am showing you here is that, in this new hybrid cloud era, you could get new resources in about 104 minutes (perhaps in a Pay-As-You-Go-Model) and moving your application from a CAPEX model into an OPEX model is going to be as “difficult” as a right-click and move. From your desk.
Yes I am oversimplifying. Of course there are a number of challenges around this (including networking configurations, end-to-end management, internal processes that need to change). I know all that. However I urge you to look at this as a half full (as opposed to a half empty) glass. As I said vCloud Connector is the beginning of a roadmap. Think about what it was 5 years ago, and now imagine where we will be in 5 years.
Have a safe journey.Massimo (twitter.com/mreferre).