This is the second post in the series I described in The Purpose-Driven Cloud. the series is an attempt to categorize the various cloud platforms available today (and that may be available in the future). Each installment examines one of the dimensions that differentiates different cloud platforms. The first in the series discussed the Usability-Driven Cloud. This post is about: --
The Framework-Based Cloud
Framework-based cloud platforms are designed to be used with a specific programming language, product or technology stack. They enable developers who subscribe to that particular programing model to focus on the innovative aspect of their application and let the platform handle the plumbing problems of scalability, reliability and performance (and in some cases, integration).
So, as you would expect, there are clouds focused on different frameworks:
Heroku and Engine Yard provide a platform-as-a-service for Ruby.
Google App Engine supports Python and Java (or more accurately, languages that run on the Java Virtual Machine, which may include JRuby, Jython, etc.).
GigaSpaces has launched a beta cloud service, which leverages its product and the Spring Framework for creating scalable apps in the cloud.
And speaking of Spring, very notable is the recent VMWare acquisition of SpringSource, which in turn acquired Cloud Foundry, with the announced intent to create a Java cloud (or more accurately, enable Java clouds, as VMWare itself does not intend to host the platform, but sell it to third-party providers).
Stax offers another platform-as-a-service specifically focused on Java Enterprise Edition (aka J2EE).
Microsoft Azure, of course, is a .Net cloud platform.
Adobe has released a beta version of a Flash PaaS back in November of last year code-named Cocomo and then renamed it Adobe Flash Collaboration Service.
PHP does not yet have a full-blown cloud service, but not surprisingly, Zend Technologies, the company behind PHP, seems to be thinking about it, and already offering Amazon Machine Images.
Stack-Support, Proprietary Models and Trade-Offs
Modern applications are of course built from many components that form a "stack". One of the key areas of differentiation among platform-as-a-service providers who support the same programming language is going to be the stack they support and the approach they've taken to support them.
There is an inherent trade-off between the level of flexibility the platform provides for developers, and its ability to transparently handle issues such as scale, performance, reliability and integration.
Google App Engine, for example, although it supports Java, requires specific threading and data models. These are non-standard development practices, if not outright proprietary. The implications of this are that existing apps require significant changes to be made in order to run on GAE, and applications written for GAE will require significant changes to be ported to other platforms. A phenomenon also known as vendor lock-in.
Heroku, on the other hand, takes a different approach. They do require applications to be written in a certain way to run on the platform. But what they require are standard best practices. In other words, while porting a pre-existing app to Heroku might require some code and architecture changes, the opposite is not true: an application written to run on Heroku would be able to easily run on other platforms and in other (including non-cloud) environments.
Also, as I pointed out in Ruby Developers: The Cloud Generation, Heroku allows interchanging different components in the stack, such as the choice to use Rails or Sinatra.
Product-Specific Cloud Frameworks
In some cases, the "framework" is a specific (usually commercial) product that is now being offered as a cloud service. A good example of this is Tibco Silver, which leverages ActiveMatrix and other Tibco products.
Final Thoughts
An argument has been made that in the end there will be a handful of mega-clouds - no more than five. This may or may not be true in the Infrastructure-as-a-Service space, due to the fact that at the end of the day IaaS is a commodity service and economies-of-scale will win the day. But is certainly not true when it comes to PaaS. As long as different development platforms, programming models and frameworks are around (forever?), their will be cloud platforms to support them (even if those platforms are eventually acquired by a few large players).
Read the next installment in this series: Domain-Specific Clouds.
