VMware Cloud Foundry … Hypervisor 2.0?

Ever since the acquisition of springsource nearly two years ago, VMware has been generating a lot of excitement in the application development space.  That excitement was kicked into high gear a few weeks ago when VMware announced the industry’s first implementation of open PaaS, CLOUD FOUNDRY.

But I have a feeling much of that excitement is not felt or even understood by the average reader of this blog.  The reason largely has to do with the fact that most of us have an IT infrastructure/operations background.  We are really good at troubleshooting low-level infrastructure stuff, we can rattle off the differences between RAID5 and RAID10, and we can debate iSCSI vs NFS until we are blue in the face.  However, while we may able to go crazy, Einstein deep into infrastructure technologies, there are very few us who would have a single clue about things like MVC software architecture, Object/Relational Mapping, or Dependency Injection.


Sure, some of us (and probably not many of us) may have the ability to create useful automation scripts in PowerShell or PERL, but that’s a far cry from being able to create a full-blown application for end user consumption.   And I’m here to tell you the application development world is, now more than ever, something we all need to embrace.  Because worlds are colliding and CLOUD FOUNDRY is a glimpse of things to come.



Well you already know that Cloud Foundry is a PaaS, which means that at a very high level, you can think of Cloud Foundry as something on-par with Microsoft’s Azure, or Google’s AppEngine, or Salesforce’s Force.com, or Engine Yard.  Not familiar with those services?  Or not 100% clear on what a PaaS is?  OK, then for now, let’s think of Cloud Foundry as a Hypervisor for cloud based applications.  To be clear, I am NOT saying Cloud Foundry is a Hypervisor (because it is not); but let’s just start there.


So today, what do we do when we want to deploy an application in our virtual datacenters?  First, we start with a VM or a collection of VMs, and we either deploy them from a template, or we start from scratch and install an Operating System.  Then, after some routine IT processes (patching, updating, configuration management, etc.) we either install and configure the application, or we hand it off to an application team to do the rest.  The key point I want to make here is you start with an Operating System and build up from there.  Meaning, the primary point of abstraction, the place upon which we begin to start build, is the Hypervisor.


How does this translate to Cloud Foundry?  Well, Cloud Foundry allows us to start building applications directly on Cloud Foundry.  There is no need to install an Operating System, nor is there a need to patch it, apply configurations, and install application components.  That’s all taken care of behind the scenes.  So Cloud Foundry becomes the main point of abstraction, the place upon which we directly build our new cloudy applications.


Another way to look at it would be, the Hypervisor switches our focus from managing hardware to managing VMs.  Similarly, Cloud Foundry switches our focus from managing VMs to managing applications.  In the former case, the hardware doesn’t go away and in the latter case, the VMs won’t go away either.  But the way we interact with, manage and even think about hardware has fundamentally changed … and so it will be with VMs and Cloud Foundry.


Again, as a point of clarification, is Cloud Foundry the textbook definition of a Hypervisor?  Nope.  But if we allow ourselves to loosely define a Hypervisor as the point of abstraction between layers of the compute stack (Hardware – Hypervisor – Operating System – Hypervisor – Application), then Cloud Foundry certainly fits the bill.


How is CLOUD FOUNDRY different from other PaaS offerings?

Now that we understand a bit about what Cloud Foundry is, I’m sure you’re wondering what makes Cloud Foundry any different than the other PaaS offerings out there.  The biggest differentiator can be summed up with one word:  choice.

Prior to Cloud Foundry, PaaS meant limited choices and ultimately PaaS meant vendor lock-in.   Writing an application for Microsoft’s Azure, as an example, means you will only be able to run your application on Azure.  I suppose that’s not a big deal if you’re 100% committed to Microsoft’s Azure solution and you’re OK with an off premise only option (Azure is not available for on premise consumption).  So there is definitely an element of vendor lock-in there.  And this is true for any PaaS offering out there today.  Whichever PaaS you go with, you are either limited in terms of the developer frameworks and application services the PaaS makes available to you, or you are limited in your deployment options (i.e. public vs. behind-my-firewall), or both.  For the customers I talk to, this is a very big deal.

But the good news is Cloud Foundry brings a big change to all of this.  Cloud Foundry has been designed eliminate vendor lock-in by offering:

  • choice of developer frameworks
  • choice of application services, and
  • choice of deployment (internal vs. external cloud).

Of course you might be thinking, “that sounds great, but ultimately we’ll have to run Cloud Foundry on top of vSphere, so we’ll still be locked in to VMware.”  Well, you would be wrong.  Yes, Cloud Foundry does run on vSphere, but it can run on non-VMware Infrastructure clouds as well.


Choice.  It’s super attractive, and it makes Cloud Foundry unique.


Why should you care?

But for you, the reader of this blog – someone who is probably focused on IT operations, not software development – why should you care?  Here’s one great reason …

If your IT shop does not like dumping the company Web app on Engine Yard but the dev team is threatening mutiny over working in a stone-age traditional Java production lifecycle (“that’s so 2005, man”), Cloud Foundry can basically become the in-house option.

— Carl Brooks, Senior Technology Writer for SearchCloudComputing.com

Another reason?  Whether we like it or not, PaaS is coming like a freight train and we need to get in front of it now. We need to embrace it.  We need to be the first to understand the Hypervisor 2.0, and all the moving parts around it.   We need to figure out how to offer it to our internal developers before they go consume it externally on their own.  Because ultimately, we will either add value to our employer and serve our users, or someone else will.  I know I’m not going to get run over by the train … are you?


What should you do next?

Here is my recommendation … be the first person in your organization to embrace and understand Cloud Foundry.  Believe me when I tell you this will pay handsome dividends for you far into the future.  To start you on your journey, here is some recommended reading …