Forward PaaS: VMware’s Cloud Foundry First Down

I know it’s baseball season, but there’s no passing in baseball and this post will just work better as a football analogy.

VMware’s announcement this week of Cloud Foundry (twitter @cloudfoundry) has gotten a lot of attention from the cloud community, and for good reason. Just as hardware is a low-margin commodity business, hardware as a service (e.g. IaaS) is the same. Ultimately, price will be the core basis for competition in the IaaS space and a lot of high-cost “enterprise” clouds will struggle to compete for business without some real differentiation.

For the past few years, PaaS offerings from Salesforce (force.com)a, Microsoft (Azure), Google (AppEngine) and newcomers like Heroku (now owned by Salesforce), EngineYard and others have really gained a lot of traction. Developers really don’t like sysadmin work as a rule, and provisioning instances of EC2 is sysadmin work. Writing code that turns into applications, features, etc. that end-users use is far more interesting to the developers I’ve worked with (and who’ve worked for me). PaaS, then, is for developers.

But PaaS before this week meant lock-in. Developers, and the people who pay them, don’t like to be locked into specific vendor solutions. If you write for Azure, the fear (warranted or not) is that you can only run on Azure. Given that Microsoft has totally fumbled the opportunity to make Azure a partner-centric platform play, that means you need to run your Azure apps on Microsoft’s cloud. Force.com is even worse – with it’s own language, data model, etc. there’s not even the chance that you can run your code elsewhere without major rework. Force.com got traction primarily for people building extensions to Salesforce’s SFA and CRM offerings – though some people did do more with it. VMforce (Spring on Force.com) was supposed to change the openness issue by providing a framework for any Java apps to run. Google AppEngine is also proprietary in many respects, and when it launched with just a single language (Python!), a lot of developers shrugged. Even the proprietary PaaS components of AWS have been a problem. I could not get my developers to use SimpleDB back in 2008 because, as the rightly pointed out, we’d be stuck if we wanted to move off of EC2 at some point.

Lots of flags on the field. Holding! Illegal receiver! Neutral zone infraction!

There have been some attempts to publish PaaS frameworks that can run on other clouds, but they have failed to gain much traction. (carried off the field on a stretcher? yeah, that works).

Along comes CloudFoundry by VMware and — INTERCEPTION!

In fact, it’s like a whole new game just started. On their first possession VMware completed a perfectly executed forward PaaS. It’s 1st & 10 on their own 20 yard line. There’s a lot of field out there, and while the defense is in total disarray for the moment, it’s going to take a lot of perfect execution to score a CloudFoundry touchdown.

The Cloud Foundry Playbook

VMware really nailed it on the launch, with very compelling playbook of offensive and defensive plays that should have most PaaS competitors reeling. Here’s their graphic that shows the core concepts:

Shotgun Formation: Across the top you can see three programming frameworks included at launch.  Spring (Java – SpringSource owned by VMware), Rails, and node.js.  You can expect more frameworks to be supported – including Python and PHP.  Ideally they would add .NET too, though not sure if the licensing can work there (a huge chunk of corporate apps are Windows/.NET based).  They also added support for MongoDB, MySQL and Redis for data management.

The Open Blitz: VMware did an incredibly good thing by launching the core Cloud Foundry project as an Apache-licensed open source project.  While I have some concerns around their lack of a community governance model, the fact that they went with Apache vs. a dual-license GPL/Commercial model like MySQL is incredibly aggressive.  I could, if I wanted to, grab Cloud Foundry code, create my own version (e.g. Bzz Foundry) and sell it for license fees with no need to pay VMware anything.  The reality is that I could, but I would not do that and VMware knows that their own development teams will be the key to long term sustainability of this solution.  That said, a cloud service provider that wants to add Cloud Foundry on top of their OpenStack-based cloud could do so without any licensing fees.  I can be part of the “Cloud Foundry Federation” without having to be a vCloud VSPP provider.

Special Teams: Cloud Foundry is deployable in an enterprise private cloud, a public cloud, or what they call a “micro cloud” model (to run on a laptop for development).  I suspect they will have a very strong licensing and maintenance business for the enterprise versions of Cloud Foundry.  They’ll also get support and maintenance fees from many cloud service providers who see the value in paying for it.  Of course, CloudFoundry.com is a service itself, which may be a problem for other cloud service providers to join the federated model.  This is something they will need to think about – EMC Atmos Online eventually had to be closed to new customers based on push back from other service providers who were looking to also be in the cloud storage business.  It’s hard to get service providers to use your stuff if you’re competing against them.

Just over a year ago I argued that VMware should “Run a Cloud…” as one of their options.  In fact, I predicted a Spring is the key to them being a cloud provider:

Their alternative at that point is to offer their own cloud service to capture the value from their enterprise relationships and dominant position.  They can copy the vertically integrated strategy of Microsoft to make push-button deployment to their cloud service from both Spring and vCenter.

Gartner’s Chris Wolf is following a similar line of thinking, especially when you add last week’s EMC -> VMware Mozy transfer.

So where does that leave Team CloudFoundry?

For now, they are on the field, in the game, and playing like winners.  Let’s see if they can march down the field before the defense gets into a position of strength.

——-

(c) 2011 CloudBzz / TechBzz Media, LLC.  All rights reserved.  This post originally appeared at http://www.cloudbzz.com/seamicro-atom-and-the-ants/. You can follow CloudBzz on Twitter @CloudBzz.

 

 

 

Tagged , , , , , , ,

9 thoughts on “Forward PaaS: VMware’s Cloud Foundry First Down

  1. […] CloudBzz frames the issue this way: But PaaS before this week meant lock-in. Developers, and the people who pay them, don't like to be locked into specific vendor solutions. If you write for Azure, the fear (warranted or not) is that you can only run on Azure. Given that Microsoft has totally fumbled the opportunity to make Azure a partner-centric platform play, that means you need to run your Azure apps on Microsoft's cloud. Force.com is even worse – with it's own language, data model, etc. there's not even the chance that you can run your code elsewhere without major rework. Force.com got traction primarily for people building extensions to Salesforce's SFA and CRM offerings – though some people did do more with it. VMforce (Spring on Force.com) was supposed to change the openness issue by providing a framework for any Java apps to run. Google AppEngine is also proprietary in many respects, and when it launched with just a single language (Python!), a lot of developers shrugged. Even the proprietary PaaS components of AWS have been a problem. I could not get my developers to use SimpleDB back in 2008 because, as the rightly pointed out, we'd be stuck if we wanted to move off of EC2 at some point. […]

  2. […] CloudBzz frames the issue this way: But PaaS before this week meant lock-in. Developers, and the people who pay them, don't like to be locked into specific vendor solutions. If you write for Azure, the fear (warranted or not) is that you can only run on Azure. Given that Microsoft has totally fumbled the opportunity to make Azure a partner-centric platform play, that means you need to run your Azure apps on Microsoft's cloud. Force.com is even worse – with it's own language, data model, etc. there's not even the chance that you can run your code elsewhere without major rework. Force.com got traction primarily for people building extensions to Salesforce's SFA and CRM offerings – though some people did do more with it. VMforce (Spring on Force.com) was supposed to change the openness issue by providing a framework for any Java apps to run. Google AppEngine is also proprietary in many respects, and when it launched with just a single language (Python!), a lot of developers shrugged. Even the proprietary PaaS components of AWS have been a problem. I could not get my developers to use SimpleDB back in 2008 because, as the rightly pointed out, we'd be stuck if we wanted to move off of EC2 at some point. […]

  3. […] CloudBzz frames the issue this way: But PaaS before this week meant lock-in. Developers, and the people who pay them, don't like to be locked into specific vendor solutions. If you write for Azure, the fear (warranted or not) is that you can only run on Azure. Given that Microsoft has totally fumbled the opportunity to make Azure a partner-centric platform play, that means you need to run your Azure apps on Microsoft's cloud. Force.com is even worse – with it's own language, data model, etc. there's not even the chance that you can run your code elsewhere without major rework. Force.com got traction primarily for people building extensions to Salesforce's SFA and CRM offerings – though some people did do more with it. VMforce (Spring on Force.com) was supposed to change the openness issue by providing a framework for any Java apps to run. Google AppEngine is also proprietary in many respects, and when it launched with just a single language (Python!), a lot of developers shrugged. Even the proprietary PaaS components of AWS have been a problem. I could not get my developers to use SimpleDB back in 2008 because, as the rightly pointed out, we'd be stuck if we wanted to move off of EC2 at some point. […]

  4. Awsome post about the topic discussed. It’s one of the best I’ve read so far!nCheersnuprightvacuumsshops.co.cc , funny halloween costumesn

  5. […] CloudBzz frames the issue this way: But PaaS before this week meant lock-in. Developers, and the people who pay them, don’t like to be locked into specific vendor solutions. If you write for Azure, the fear (warranted or not) is that you can only run on Azure. Given that Microsoft has totally fumbled the opportunity to make Azure a partner-centric platform play, that means you need to run your Azure apps on Microsoft’s cloud. Force.com is even worse – with it’s own language, data model, etc. there’s not even the chance that you can run your code elsewhere without major rework. Force.com got traction primarily for people building extensions to Salesforce’s SFA and CRM offerings – though some people did do more with it. VMforce (Spring on Force.com) was supposed to change the openness issue by providing a framework for any Java apps to run. Google AppEngine is also proprietary in many respects, and when it launched with just a single language (Python!), a lot of developers shrugged. Even the proprietary PaaS components of AWS have been a problem. I could not get my developers to use SimpleDB back in 2008 because, as the rightly pointed out, we’d be stuck if we wanted to move off of EC2 at some point. […]

  6. andrewbadera says:

    Wherefore art thou, .NET? VMWare needs to roll Apprenda’s SaaSGrid product into this offering.

  7. Rawkesh singh says:

    Actually student needs part time jobs to make their pockt money and other expenses and we are offering part time jobs for students.u00a0http://www.mp3fundoo.com/don-2-songs-free-download.htmlhttp://www.mp3fundoo.com/aadat-se-majboor-songs.html

  8. Tanvi says:

    This is a perfect time to say that you affected me with your perfect story related to this good post.nEk Main Aur Ekk Tu songs

Comments are closed.

%d bloggers like this: