As mentioned in a number of posts, there is a clear trend away from Platform-specific PaaS (where you write your application to the platform) and Language-Specific PaaS (which provide support to one or possibly a couple of languages) to Universal PaaS, which is capable of supporting any language and any platform. There’s a little bit of a gray area, but we would include ActiveState Stackato, AppFog, dotCloud, GigaSpaces Cloudify, Red Hat OpenShift, Salesforce Heroku, Uhuru Software AppCloud and VMware CloudFoundry in this category. These vendors differentiate themselves by providing a broad range of Application Services or Application Lifecycle Services.
The core of a PaaS is an “orchestration” layer which takes the application in the form provided to it, configures and replicates it as required and distributes it into the software environment it needs to operate, configures that environment, and invokes and controls the application to run inside that environment. In addition there will be other non-core elements which are often known as Services.
The “Services” terminology is quite confusing, and we will generally try and refer to them as “Application Services”, by which we mean they provide services to an Application as it is running (examples include messaging services, database services, email services etc.). There are also often elements of a PaaS which relate to software configuration management, team-working and testing – we refer to these as “Application Lifecycle Services”.
In Platform-specific PaaS (Salesforce, Mendix etc) the value proposition is the platform and vendors provide an integrated solution including the Core Platform as well as all Application Services and Application Lifecycle Services, development tooling, management tooling and in some cases the public cloud implementation. In both language-specific PaaS and Universal PaaS, the value-proposition is the ability to support any platform, and so the vendor has to provide a broad range of Application Services and Application Lifecycle Services.
It simply isn’t possible for a single vendor to provide all Application Services itself, so Platform-specific PaaS and Universal PaaS vendors may choose to support a small range of services directly, and to provide links to external services for additional functionality, scalability or fault tolerance. For convenience a PaaS vendor may bundle the licensing and access to these external services into its own price list. In public PaaS the services are generally accessed remotely and may be referred to as Monitoring as a Service, Database as a Service etc. or more generally Application Services as a Service (ASaaS).
Universal PaaS is just emerging into the marketplace in Generally Available form, and it is emerging from one of two types of vendors
- a “second-generation” of new PaaS vendors – many of which are basing product on the open source CloudFoundry.
- first-generation PaaS vendors (with previous language-speciifc or platform-specific PaaS or both) expanding product strategy to deliver a Universal PaaS (by acquisition, and/or expansion of product features or adoption of CloudFoundry)
A broad ASaaS partner set should be considered a good sign in a Universal PaaS and we have noticed quite a significant difference in the range of Application Services that are being offered alongside the core platform in the initial offerings of Universal PaaS vendors. It is clear that those Universal PaaS vendors that had established a successful Language-specific PaaS have already developed reseller relationships with a broad range of third parties to supply external Application Services and Application Lifecycle Services alongside their platform. Particularly good examples include Salesforce Heroku and Appfog.