What Exactly is Cloud Foundry?
The PaaS on PaaS marketure has me confused. The ecosystem surrounding Cloud Foundry demonstrates how PaaS, the middle level between SaaS and IaaS is actually a multi-layered market space. A way to unwind the recursive relationship between Cloud Foundry and ecosystem partners is to first start calling the technology a ‘cloud-enabled platform’, and limit PaaS as an instantiation of the cloud-enabled platform delivered as a service. The CloudFoundry ecosystem partners (e.g. AppFog, Stackato, Uhuru, Tier3) seem to be competing on ease of use enhancements, bundled technology (e.g. language support, cache support, database support), or managed hosting.
I get confused when I hear AppFog or Stackato described as PaaS’ running on top of Cloud Foundry, which is also marketed as a PaaS. It becomes non-trivial to characterize the differences between offerings, but the vendors themselves are starting to sort out the nomenclature. In fact, Stackato is now promoting their offering as “The cloud platform for creating your private PaaS” and AppFog defines their offering as “a cloud-based hosting service for your favorite web application stack”. Under a more defined and consistent nomenclature, Stackato could be considered a cloud-enabled application platform build on top of Cloud Foundry, and AppFog considered as a Platform as a Service built on top of Cloud Foundry.
But the last paragraph still doesn’t describe ‘What is Cloud Foundry?’ Cloud Foundry self-describes their offering as “an open platform as a service, providing a choice of clouds, developer frameworks and application services”. But the open source project is not a service; it’s a cloud aware application execution framework, which sit underneath a traditional application platform and application frameworks (e.g. .NET, Java, Sinatra, Tomcat, Rails). Cloud Foundry capabilities are actually of little direct use to an application developer; unless during the time when the developer is building servers or deploying an application. The Cloud Foundry core does not help a developer design, code, or test applications (where hopefully they spend a majority of their time).
Cloud Foundry and ecosystem partners are focused at a different abstraction level when compared with traditional, integrated, full-spectrum application platform suites (i.e. IBM WebSphere, Oracle SOA Suite, Tibco ActiveMatrix, or WSO2 Carbon). Application platform suites deliver high level APIs and components, which accelerate solution development. For enterprise development, teams often require a comprehensive, full-spectrum application platform delivering web application-hosting, service hosting for data and process, data persistence and queries, identity and entitlement (i.e. authorization, authentication, audit), mediation and transformation (often delivered via an ESB or gateway), workflow, presentation, rules, and development governance. Figure 1 below presents the full-spectrum of components:
My passion is to help teams architect and rapidly build solutions by using highly capable application platform services, delivered at the right level of abstraction. I have a few blog post describing how to understand Cloud dimensions, simplify Platform as a Service complexity, review Platform as a Service reference architecture, and select a Platform as a Service offering.
I have posted a presentation Introducing Platform as a Service (PaaS), which describes my view of the Platform as a Service space in more detail.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)