[Blog Post] Enterprise Private PaaS Adoption and Differentiation
- By Chris Haddad
- 28 Jul, 2013
The secret is starting to leak out from multiple sources; Private PaaS adoption by enterprise end-user organizations is off to a slow start in 2012-2013. Application development teams are missing an opportunity to accelerate their agility and operate at the speed of Now. As enterprise teams evaluate Private PaaS alternatives and PaaS architecture, they must carefully identify cloud benefits, cloud characteristics, cloud-native platform options, and cloud adoption strategies.
Mike Kavis of Cloud Technology Partners affirms the slow adoption pace and need for a structured evaluation model.
The adoption rates of PaaS in the enterprise were slow prior to 2013. Enterprises are aggressively evaluating PaaS in 2013 as a key differentiator. The challenge is that there are many different deployment models and application stacks supported by numerous vendors.
While Public PaaS only requires a simple, on-demand subscription process and uploading code into the Cloud, Private PaaS requires transforming enterprise IT deployment models, monitoring and management systems, operation processes, funding models, and platform configuration options.
Changing internal IT processes, infrastructure, and people skills is not easy, and often, complicated IT initiatives do not obtain the initially promoted lofty goals. Scott Bils states many Private Cloud initiatives are failing to move forward:
Off the record, many in the IT consulting and SI business will say the majority of private cloud pilots they’re seeing aren’t going well. In fact, some believe that up to 90% of private cloud pilots in the enterprise will fail to move forward.
Given nascent Cloud best practices and few true cloud architecture blueprints, successfully launching a Private PaaS requires trail blazing vision, game changing metrics, strong change management, and effective communication.
Even defining ‘What is Private PaaS’ can prove complex. Consider the following use cases:
- A platform wrapping traditional platform servers, frameworks, and languages (e.g. Tomcat, Spring, Java) and extending the traditional environment with Cloud characteristics (e.g. elastic scalability, resource pooling, on-demand subscription. – PaaS Framework
- A platform supporting enterprise integration patterns – Integration Platform as a Service (iPaaS)
- A platform supporting web application development – Application Platform as a Service (aPaaS)
- A platform supporting publishing services and managed APIs – no fancy acronym yet.
- A platform supporting business process execution – Business Process Platform as a Service
- A platform delivering application lifecycle management tools delivered as a shared service (ALM PaaS)
- A platform facilitating DevOps practices of continuous delivery – DevOps PaaS
- A platform enabling collaborative development by partners and a shared SaaS deployment model – Ecosystem PaaS or Community PaaS
- A platform delivering domain specific frameworks for vertical industry participants (e.g. banking, insurance) – Industry PaaS
Enterprise architects who are defining a Private PaaS Roadmap must carefully specify target project use cases, quantify to-be architecture, and map Private PaaS platforms.
While Private PaaS market traction has been limited to date, my colleague, Yefim Natis, has been quoted to say:
The direct revenue in the PaaS market grossly underestimates the importance of this part of the cloud architecture.
Because WSO2 recently donated Stratos to Apache (and the associated Stratos trademark), we are re-branding our PaaS offerings. What taxonomy should we use to promote our comprehensive, Cloud-Native platform across multiple PaaS use cases, while minimizing brand/product names? How can our clean, composable architecture heritage shape our Cloud messaging and value proposition?
Private PaaS Layers Defined
A message proposal could be:
- Apache Stratos
- WSO2 Private PaaS Framework
- WSO2 Cloud Platform
- WSO2 App Factory
The four are Private PaaS offerings, each delivering a different value proposition.
Apache Stratos is a community supported Open PaaS. Competitors include Cloud Foundry Project and Red Hat OpenShift Origin.
WSO2 Private PaaS Framework will be the WSO2 supported distribution of Apache Stratos. The enterprise support for Apache Stratos will compete against Red Hat OpenShift Enterprise, ActiveState Stackato, Apprenda, and the numerous Java PaaS frameworks that accept plug-in application platform components.
The WSO2 Cloud Platform includes WSO2 Private PaaS Framework plus one or more Cloud-Native Carbon middleware components. The WSO2 Cloud Platform delivers application services required to run a complex, enterprise application. The PaaS may be configured with WSO2 Enterprise Service Bus, WSO2 Governance Registry, WSO2 Identity Server, and WSO2 API Manager to deliver integration Platform as a Service (iPaaS). Alternatively, the PaaS may be configured with Tomcat, WSO2 User Engagement Server, WSO2 Identity Server, and WSO2 Storage Server to deliver an application Platform as a Service (aPaaS) environment. The possible number of fit-for-purpose PaaS configurations is 15 factorial, yet each platform combination will share a common PaaS foundation, role-based security, management, and billing functions. Competitors include all the Java PaaS vendors, Apprenda, Jelastic, Heroku, MuleSoft, and others…
WSO2 App Factory is a DevOps PaaS that is created by augmenting the WSO2 Cloud Platform with deployment scripts (using Puppet or Chef), Jenkins, enterprise governance, ALM tooling, and integrating continuous delivery processes. Competitors include GigaSpaces Cloudify, CloudBees, Collabnet CloudForge, and CloudMunch. While competitor capabilities overlap with WSO2 App Factory, each competitor delivers only a portion of WSO2 App Factory capabilities.
WSO2 App Factory goes beyond DevOps infrastructure as code and continuous delivery practices by incorporating enterprise project lifecycle governance, integrating ALM tooling, and coordinating with Private PaaS run-times.
What capabilities have you defined for your Private PaaS environment? What use cases define your Private PaaS environment? How should vendors associate their Private PaaS offerings against key market categories?