PaaS - How will it be priced?
CloudBees is in an interesting position being so far ahead of the rest of the competitors in the Java PaaS space. We have a GA offering that is basically competing with Beta versions from VMWare (Cloud Foundry) and Red Hat (OpenShift). So we have to price our full offering ahead of our competitors.
We all have free versions. Given the market is early, this might be the most important thing today given that a lot of people want to experiment and learn and understand how the Cloud can play in their development and deployment cycles. It is likely we will all keep free versions. For example, CloudBees offers up to 300 free minutes of Jenkins build time per month on the dev side (lots more for Open Source Projects) and up to 5 apps on the RUN@cloud side. Of course those 5 free apps are not scalable, or have high availability or have SSL or have custom URL's. But certainly very useful for learning, testing and even small apps that are non-critical.
The interesting part comes when trying to figure out the pricing for running this in production. CloudBees has made our pricing public, and we think it is very competitive to the alternative of having to own your own hardware, operating system, virtualization, webservers, application servers, database servers, repositories, Jenkins, etc. Not to mention installing, configuring and maintaining that stack. And of course only paying for what you use. Oh, and the nice benefit of having "instant on".
Of course we have to play a bit of a guessing game as to where our two major competitors will end up later this year or early next year when they finally go GA. My guess is they will be significantly above us given they have an installed base to protect. Just look at the VMWare stack diagram above. CloudFoundry is just a little green box at about 1 o'clock, and when coming from VMWare will likely be packaged with other things like vSphere, vCloud, vFabric (Spring) and management tools. If you buy those today they cost $2-5K per CPU depending on configuration. My guess is that VMWare can not say goodbye to $2B in revenue by giving those components away or by devaluing them by bundling them in CloudFoundry.
I heard from a mutual partner that Paul Maritz says they want to commoditize the PaaS to keep the value in their other components.
You can also get a sense for where they stand with the recent vFabric 5 (Spring) announcement in this article - "Our approach ensures that the best place to run any of your applications is on vSphere, and secondarily, vSphere is the very best place to run your Spring applications" says SpingSource's David McJannet. My educated guess is they will take a similar stance with Cloud Foundry.
While at Red Hat summit we heard rumblings from the RHEL sales force that hints at the kind of internal battles and real revenue continuation program they must have to protect their installed base of RHEL and JBoss.
What this all adds up to is that CloudBees will have a competitive advantage since we are unencumbered by running on specific stacks and do not have revenue streams to protect there. This means we will be able to charge prices to customers that will continue to save them money from their existing stacks. This will become more clear as we make announcements over the course of this year where we run on alternate stacks - giving customers a lot of flexibility and freedom of choice in where and how they take advantage of the Cloud. It should be fun...