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 characteristics, Cloud 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:
- PaaS Framework
- PaaS Framework + Middleware
- 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?