vSphere, vCloud and the Meaning of being “Open”

This article was originally posted on the VMware vCloud corporate blog. I am re-posting here for the convenience of the readers of my personal blog.

This year’s VMworld was crazier than ever—and a return to our geekier roots. And, as I promised in an earlier post, this year’s event would be a lot of fun for those attending for the simple reason that geek=crazy=fun. Well, I can proudly say I delivered on my promise. Hmm, this sounds like VMworld was my thing whereas, I just helped (not even that much) to make it the success that it was.

One of the things getting a lot of buzz this year was all the arguments about what it means to be “open”. Yeah, right, what on earth does that mean anyway?

I think being open means a lot of things to a lot of different people. When I started my adventure at IBM 16 years ago we would have called Windows and the UNIX platforms “open”. In 2010, if you were to call Windows, AIX or HP-UX “open” many people would laugh at you. So what on earth does "open" mean, then?

In my opinion, it fundamentally boils down to two very different definitions depending on who you are or, what you do. On one hand, it has more to do with open source. On the other hand, it can refer to the concept of "choice" and avoiding “lock-in”.

Now, let me make one caveat. If you are in the business of making money out of hacking source code, or you are in the business of taking advantage of fixing a bug in a piece of software that you downloaded off the Internet, please make sure you stop reading. This post is probably not for you.

However, this post is for those people that make money out of everything else than the two scenarios described above. And based on my experience this is the vast majority of the market participants out there. So I’ll make a bold statement and say that most of the people look at this matter from a “choice” vs. “lock-in” perspective. With this in mind I’d like to walk through what we at VMware are trying to do to make vSphere and vCloud open. Again I want to remind you that I am going through this with the eyes of the end-user (i.e. a VMware customer) and not with the eyes of someone that is trying to leverage the open source code to build something fancy for either the sake of doing it, or for selling it to the end-user in some way.

Let's start with a picture. I’ll walk step by step through it to explain how we’re creating an open platform for cloud computing.

First step: virtualization

This is easy. VMware customers buy vSphere and they have a tremendous choice of hardware platforms to choose from with regards to servers, storage and network subsystems. While VMware is adding a layer of abstraction, we are certainly not in the business of commoditizing that. Almost every vendor out there has been using our APIs to expose their own peculiar features inside our environment and we have leveraged those features to provide our joint customers with a better experience. This is, for example, what EMC and NetApp have done for years now from a storage subsystem perspective.

By the way, I had an interesting discussion regarding this matter: someone was making the point that if he had leveraged a particular vendor's feature that all the other vendors did not have, he would be effectively locked-in to that vendor. That was an interesting point of view. I’d look at the thing in a very different manner: typically any of these special features build on top of standard functionalities so you have a choice of either going back to the standard functionalities or continue to use that vendor for that peculiar feature. For the records this is called innovation, not lock-in.

Okay, so at this point some of you may be thinking that you are locked-in to the VMware abstraction layer. I wouldn’t say that. There are tons of tools out there capable of doing Virtual to Virtual (V2V) and I can tell you it wouldn’t take too much to convert your VM into another format to run onto another hypervisor. Come on folks, we are not talking about one million lines of COBOL that you can’t possibly rewrite, so you are stuck forever on your mainframe. We are talking about a button or, a drag and drop operation, where you say: “I want to move this VM from here to there”. It’s as simple as that.

Yet, I haven’t seen this happen very often. Why is that? Because many of the VMware end-users understand that the value they are extracting from our software is well worth the money they are spending. And if you feel someone didn't want to leave the platform because of its unique value proposition, I encourage you to think about the innovation vs. lock-in paragraph above. These customers have a choice, but they have chosen not to leverage it, and for good reason, I’d say! They can always do this in the future if they want; I don’t see the V2V tools disappearing anytime soon.

In addition to this the standards that are being created, like the Open Virtualization Format (OVF) for example, will make this flexibility even more evident. Furthermore, we have been promoting this standard because we want to keep our customers and make them happy based on value delivered and not based on lock-in tactics.

Second step: Jumping into the Cloud

Now, let's change gears. The phase we are entering in today is all about helping customers to extend (if they want) their private (i.e. internal) deployments into the public cloud, which effectively creates a hybrid environment. During my session at VMworld I demonstrated a very neat (I believe) piece of technology we are working on that allows you, from your vSphere client, to map a portion of a public cloud and either instantiate your templates there, or move an existing workload there–and all from the same interface. This is a technology preview of something called the vCloud Client Plug-in.

So, what do I mean by “map” anyway? That’s where the vCloud program comes into play. Our service provider partners are using VMware vCloud Director to implement a standard interface based on the vCloud API, which, in turn, has been submitted to the Distributed Management Task Force (DMTF) for cloud standardization.

So, essentially, our end-users have a choice of connecting to different service providers to source the additional capacity. This would allow them to extend their local datacenters into the cloud. Let me reiterate a key point: customers have a choice of service providers. You can see this as very similar to the experience I have described above to source in-house server, storage and networks leveraging multiple OEM partners. In fact, each service provider would deliver core functionalities, as well as, add-on functionalities that you may find attractive depending on what you are trying to achieve. See my point above regarding innovation.

Now, from an end-user perspective, we should be covered because you have a choice of selecting your preferred source of capacity, be it an OEM or a service provider. Of course, as I said, you have also the choice of using V2V tools to move away from the local vSphere platform if you chose to do so.

Let’s turn to the service provider side for a moment. If you are a service provider you may find it appealing to federate with some of the 190,000 VMware vSphere customers out there by helping them run a better overall IT service.

You may think these service providers would need a VMware “stack” to provide these on-demand services. Well, while I would personally say that this should be arguably considered their best choice, this not technically accurate. It all boils down to exposing the vCloud API to the end-user. VMware vCloud Director would be able to expose them for you out-of-the-box, but you can go ahead and build that layer and interfaces for yourself since the vCloud API is well documented.

You can even go a step further and choose not use vSphere if you wish. If you want to federate with vSphere end-users the service provider would have to deal with having to change the disk format from the Virtual Machine Disk Format (VMDK) to another format. Arguably, this may not be the smartest thing to do, but it is something you can technically do. Most of the service providers I have been working with are telling me that they are not in the business of creating this "cloud backbone". What they are telling me is that they want to buy that backbone as an off-the-shelf product. And, that brings me to the next and last point.

The last concern for service providers is how they can differentiate their offerings among one another. I covered this topic in another blog post, but in a nutshell what I’m talking about is the backbone for creating an infrastructure-as-a-service (IaaS) cloud-based backbone. The service provider has at least a number of things they can do to create customized and unique services on top of this backbone. I am talking about "unique" services in the context of innovation of course, not lock-in.

In conclusion, it appears to me that no one is locked-in to VMware and everybody—customers and partners alike--has a lot of choice. I don’t know if that qualifies as “open” but calling it “closed” is certainly a marketing stretch. (Or wishful thinking on the part of our competitors.) That’s my opinion at least. If you have a different take, then I’d like to hear that too.