PaaS Frameworks, PaaS Middleware, and DevOps PaaS

A teams review PaaS Framework and PaaS middleware offerings, understanding goals, benefits, and capabilities will influence PaaS project success.   Johan over at Mendix has recently defined a consistent and coherent taxonomy, and  I have been comparing his PaaS view with how WSO2 differentiates our Private Enterprise PaaS offerings.

While, Johan does good work describing the difference between Foundational PaaS (AWS S3, OpenStack Swift) and application PaaS (aPaaS), he seems to lump most of the PaaS offerings into his Layer 3 level.   Cloud Foundry, WSO2 Stratos, and Windows Azure Services are lumped together without discernment.     Also, the vendors presented are incomplete, as Cloudbees, IBM, Oracle, Apprenda,  OrangeScape, and Cloudmunch, are not mentioned.

As marketing folks have defined anything below a Cloud application and above Cloud compute as PaaS, a more differentiating segmentation is required to compare product offerings.   A strong focus on Cloud characteristicsCloud Architecture, and New IT drivers will ensure that you are not Cloud Washing your initiative.

As mentioned in the Selecting a Cloud Platform evaluation whitepaper, choosing the appropriate PaaS goes well beyond simply buying into model driven development and deployment in the Cloud.

When to choose PaaS Frameworks, PaaS Middleware, and DevOps PaaS?

Johan’s Layer 2 and Layer 3 levels may be segmented by the following taxonomy:

  1. PaaS Framework
  2. PaaS Framework + Middleware
  3. PaaS Framework + Middleware + DevOps + Application Lifecycle Management

(Note: Johan’s Layer 2 DevOps misses the point that DevOps needs to consider the developer perspective and be integrated into the middleware tools and application lifecycle management processes)

Each successive level provides faster time to market, enhanced portfolio efficiency, and increased team productivity.   While throwing around TTM, efficiency, and productivity buzzwords makes for good marketure, how can you measure the difference in your proof of concept projects?   Consider the following form-factor evaluation framework:

Goal Category Metric Market Category Assists
  PaaS Framework PaaS Framework + Middleware PaaS Framework + DevOps + ALM
Time to Market Time and effort to create new application environment Yes Yes Yes
Time to Market Time to redeploy application Yes Yes Yes
Time to Market Time to promote application into a new lifecycle phase No No Yes
Portfolio Efficiency Ability to dynamically right-size infrastructure and elastic scalability Yes Yes Yes
Portfolio Efficiency Ability to re-use existing platform services and business services from resource pool instead of re-building solution stack No No Yes
Productivity Time and effort required integrating business process, event processor – creating a complex app. No Yes Yes
Productivity Time and effort required to apply policy across tenant(s) Yes Yes Yes
Productivity Cost to operate application per user or transaction measured against the value provided by the application or transaction. Partial Yes Yes


Within each category, WSO2 differentiates their PaaS offerings (Apache Stratos, WSO2 Private PaaS, WSO2 Cloud, and WSO2 App Factory) based on the following capabilities:

  • A complete set of middleware services (e.g. integration, API, web services, web applications, event processing, registry, business activity monitoring)
  • Increase team collaboration and reduce wait states by supporting DevOps processes and Application LifeCycle Management practices with Cloud run-time infrastructure
  • CxO dashboards and delivering portfolio visibility (e.g. app/API usage, app/API spend, project pipeline) and demonstrating IT efficiency (e.g. on-time, on-budget, component/API re-use); Development and DevOps dashboards presenting activity, iterations, and project blockers.
  • Lowest run-time cost based on in-process application platform resource sharing yielding industry-leading tenant density
    • Tenant-aware and service-aware load balancer optimizes application platform service sharing
    • OSGI based tenant-isolation leads to reduced application platform license (or subscription) cost
  • aPaaS auto-scale functionality reduces DevOp burden by eliminating need to explicitly define application topology
    • dynamic, policy based partitioning and provisioning of private and shared tenant resources
    • Automatic, flexible topology provisioning across private, managed, and public Clouds
  • Presents an Application Platform Service view to development teams instead of an infrastructure detail view
  • Big Data Analytics and Complex Event Processing capabilities for Adaptive Business environments


What are your most important reasons for adopting a PaaS, and how will you measure your success?


One thought on “PaaS Frameworks, PaaS Middleware, and DevOps PaaS

Comments are closed.