Strategic business growth goals often include delivering new lines of business, selling through new distribution channels, expanding into new geographical markets, simplifying business workflow, delivering services directly to customers, and interacting through mobile channels.  A limited capital environment and short investment timeframe requires building a flexible business service model, which relies on customizing existing products and operational models.

The execution plan should highlight capability configuration and rapid, efficient business service delivery.  Business leaders often specify ‘branch in a box’, ‘localization and centralization’, and ‘on-demand self-service’ terms to indicate doing more with less, fulfilling local compliance regulations while preserving core business processes, and quickly delivering a comprehensive solution into remote areas.

Today’s business evolution pace reduces the optimal time to market and decreases the available IT execution window.  In many organizations, re-inventing software delivery is a pre-requisite before effectively executing business strategies.  CIOs are tasked with determining how IT technology, processes, and organizational models must change.  When determining whether your IT organization should re-invent software delivery to enhance execution, consider your existing architecture flexibility, team productivity, and historical time to market.

For example, a well-known business supply company asked the IT team to deliver a mobile application within 90 days.  The business required a complete, mobile shopping and checkout experience mirroring the company’s online ecommerce website.  Unfortunately, the existing application architecture lacked critical, required functionality inside the website.  The code base exposed only 50 percent of the required ecommerce business processes.  One year later, the company finally released the mobile application, and the business viewed the CIO’s team as a market growth inhibitor.

A CIO for a property and casualty insurance company authorized a service-oriented architecture (SOA) initiative in September 2003.  Seven years later, the CIO was being questioned about a $3 million yearly budget line item.   The line item funded the IT-led SOA initiative.  The CIO’s directors could not quantify the business value derived from the SOA initiative and stated that the initiative would take three more years (and an additional $9 million) to complete.  The business continually questioned the IT team’s service development productivity and fiscal responsibility.

A third CIO leading a financial services company owned a monolithic, legacy Web application architecture.  Although the architecture was only four years old, the architecture impeded the organization’s ability to deliver new lines of business and match the expected business volume.  Executive management was hesitant to migrate the application to another platform due to the business disruption encountered during the last platform rollout.  The IT team was unable to quantify the risk and value expected by a new platform initiative, and executive management perceived the CIO as pursuing new technology for technology sake.

Re-invent software delivery

All CIOs must continually lead their teams to improve how projects are designed, developed, deployed and measured.  Transformation charters commonly specify improvement through agile development methodologies, outsourcing, deploying pre-packaged applications, implementing SOA, or adopting platform-as-a-service (PaaS).   When scaling IT initiatives to meet business goals, a strategic, CIO-led technology plan is often required to overcome organizational inertia and re-invent software delivery.

Consider the following four-step strategic technology plan to re-invent the software delivery process:

1. Identify core business capabilities and outsource commodity.
2. Iteratively build extensible, configurable business services, APIs, and applications.
3. Increase business partnerships with API management that provides on-demand, self-service and analytics.
4. Host services, APIs and applications on a multi-tenant platform and facilitate per-tenant configuration

Step 1. Identify core business capabilities and outsource commodity

When teams gain consensus on their core business capabilities and define non-core, commodity processes, they have established a foundation to focus development effort and increase IT impact.  Non-core, commodity processes should be outsourced and supported by packaged applications.  Reducing bespoke, custom development frees resources and directs the team towards generating meaningful competitive advantage.  Business capability modeling is a technical discipline closely aligned with business process improvement.  CIOs should allocate a few smart architects to work with existing business process improvement experts (e.g. Six Sigma Black Belts, Kanban experts) and track core business capabilities.

A registry can be used to track the intersection between business capabilities and application assets.  Ideally, the registry would be linked with the operational configuration management database (CMDB) to provide a complete view of how business capabilities are instantiated across the IT environment.

Step 2. Iteratively build extensible, configurable business services, APIs, and applications

Pre-built functionality reduces time, effort and resources required to field new solutions.  When building services and applications, the architectural principles of extensibility and configurability will create opportunities to adapt solutions for new geographies, product lines, and markets.   Architects must be adept at identifying the commonality from the variability, and teams must iteratively build solutions to evolve and endure, rather than build for single use or to throw away.  Effective CIOs establish architecture review and governance boards to consistently evaluate development, align extension points with the business strategy, and iteratively enhance the portfolio.

When the organization identifies strategic growth opportunities in developing economies and new markets, application architecture must shift from silos and toward services.  Silos decrease business efficiency by fragmenting the user experience, increasing data management challenges, and fostering process isolation. Agile methodologies highlight inclusive engagement and user feedback.  With the correct focus, development initiatives can unify workflow, foster collaboration, facilitate consistency, and promote solution cohesion.  A complete, composable, cohesive, and interoperable middleware platform will encourage holistic service development.

Step 3. Increase business partnerships with API management’s on-demand self-service and analytics

Many CIOs experience rapid portfolio proliferation and sprawl, but not enhanced portfolio efficiency or business agility.  Achieving business agility requires the growth of development partnerships and interactions, which should span both internal and external teams.

Traditional SOA and integration platforms enable rapid development, but they provide little business partnership support.  Teams commonly operate independently and autonomously.   Hundreds of people write new APIs and services; few people know:

• who is consuming APIs and services,
• who is writing re-usable APIs and services, or
• how APIs and services are being used.

Teams must improve cross-team (or cross-partner) communication, coordination and collaboration.  CIOs should encourage their teams to extend the governance registry and offer managed APIs through an API Store.  A managed API is:

• Actively advertised and subscribe-able
• Available with an associated, published service-level agreement (SLA)
• Secured, authenticated, authorized and protected
• Monitored and monetized with analytics

An API Store is a venue to find, explore, subscribe and evaluate available resources.  The API Store enables partners to quickly find relevant APIs.  Once a candidate list is identified, the API Store provides a structured environment for exploring the APIs and understanding solution fit.   During the exploration phase, collaboration between the potential API consumer and provider is essential.  After finding and exploring an API, a project may stall when the team attempts to gain access.  An API store provides on-demand self-service subscription and collaboration channels, rapidly reducing the time and effort required to integrate and evaluate available API resources. Figure 1 illustrates API consumer lifecycle activities.

Figure 1: API Consumer Lifecycle Activities

When selecting APIs, trust is an important consideration.  Without trust, potential business partners will choose other alternatives or build their own solution.  CIOs must establish an environment where their team is the trusted provider of choice.  When teams follow best practices, partners recognize competency and reduce their adoption trepidation.

Teams increase competency when they establish a separation between API provider and API manager responsibilities.  An API provider is responsible for building, publishing, scaling and versioning the API.  The API manager is focused on promoting and encouraging potential consumers to adopt the API.   The manager analyzes usage patterns and determines how to best monetize the asset.  A monetization strategy solve a perennial IT questions:

• “Once I offer an API, what should be the show-back, charge-back mechanism?”
• “How do I actually perform investment re-capture activities?”

Step 4. Host services, APIs and applications on a multi-tenant platform and facilitate per-tenant configuration

Offering a business capability as a one-size-fits-one API is a typical IT solution trap.  One-size-fits-one solutions do not exhibit the adaptability or agility required to fulfill new business opportunities.   CIOs are intrigued by the cloud’s promise to create a one-size-fits-ALL solution.  Cloud characteristics and vertical PaaS accelerate the IT team’s ability to deliver solutions that support business growth objectives.

Cloud characteristics advance a company’s ability to offer business capabilities as on-demand services.  Cloud characteristics describe IT’s ability to deliver on-demand self-service, rapid elasticity, resource pooling, and measured service.  Figure 2 associates cloud characteristics with architectural goals.

Figure 2: NIST Cloud Characteristics and associated architectural goals

On-demand self-service and resource pooling will flexibly assign workloads and decrease provisioning periods.  If teams excessively customize an environment, they can increase time to market, lower resource pooling, and create a complex, one-size-fits-one environment, which is difficult to manage and maintain.  A CIO should encourage a governance process that minimizes exceptions.  Consumers in a one-size-fits-all environment will predominantly subscribe to standard service offerings.

Business users don’t really care how many server instances are running in the cloud.  Business users care about business entities, business activity performance, and associated cost.  A CIO who decouples metering and billing from IT assets and shifts the reporting model to focus on business activity cost will positively transform investment conversations.

When you pre-build vertical industry APIs and vertical industry components, you can decrease time to market, bring new partners online, and create new revenue sharing opportunities.   With a vertical PaaS, your organization offers vertical business capabilities using a multi-tenant, extensible cloud environment.  The environment decreases time to market for partners, creates new ecosystem scenarios, and enables revenue sharing opportunities.

The vertical PaaS environment also provides an opportunity for your partners to deeply embed your business capabilities within their applications (similar to Force.com, eBay sellers, or Amazon Store environments).  By hosting all business partners (e.g. suppliers, customers and employees) within a multi-tenant environment, the environment can easily aggregate and share business information. Figure 3 illustrates how a complete middleware platform, API management, and vertical PaaS deliver an ecosystem platform.

 Figure 3: Vertical Platform as a Service Environment

Summary

Today’s business evolution pace reduces the optimal time to market and decreases the available IT execution window.  The resulting IT mandate to rapidly offer core business capabilities as configurable services is forcing CIOs to re-invent their software delivery.  A strategic plan can keep your team on track.  Guide your team towards identifying core business capabilities, building extensible and configurable business services, increasing business partnerships, and building a business ecosystem.  As your business ecosystem emerges, your organization will encounter new revenue sharing opportunities, and an opportunity for your partners to leverage your core capabilities in ways that you haven’t yet envisioned.

Download the PaaS TCO worksheet to determine multi-tenant, shared container value.

WSO2 clients are considering running middleware as a service instead of deploying traditional middleware silos.  For example, running ESB-as-a-Service across multiple tenants.  The clients are interested in potential cost savings and vendor alternatives.  As mentioned in the ‘Searching for Cloud Architecture’ and PaaS Evaluation Framework blog posts, most PaaS environments, while delivering an application platform as a service, require a dedicated resource pool per tenant application.  For example, a tenant application hosted on Jelastic PaaS will be bound to a set number of Tomcat servers.  Server container level tenancy (e.g. Jelastic, Amazon Beanstalk, RedHat OpenShift, CloudBees) contrasts with shared container tenancy.  In shared container tenancy, tenant applications share a common pool of Java server containers.  The Java server container is dynamically shared across multiple tenant applications.  In single tenant, dedicated container PaaS, significantly more PaaS TCO expense is required to run a PaaS environment compared with a multi-tenant, shared application container PaaS.

The proposed PaaS cost evaluation tool compares multi-tenant, shared application container PaaS TCO with single tenant, dedicated container PaaS TCO (i.e. traditional application server deployment in Cloud) across multiple tenant counts and application platform service combinations.

The worksheet incorporates application platform license (or subscription) cost, PaaS Management service cost, infrastructure expense, and IT management overhead.  Across all scenarios, the worksheet calculates cost when application platforms are deployed on Infrastructure as a Service (IaaS).

Since both a shared application container PaaS and single tenant PaaS can scale up/down on-demand, the worksheet excludes savings derived from on-demand provisioning and teardown.   Instead, the worksheet calculates expense based on the maximum number of JVM instances required for steady-state workloads.

The worksheet does not depict intangible savings derived from faster time to market.  Since the scenarios assume traditional web application architecture, container-level isolation via OSGI, and application clustering (instead of stateless message passing), application migration cost and development cost will be equal and are excluded from the calculation.

Cost Calculation Methodology

The worksheet reflects the following cost components:

• Application Platform Subscription (or license fee)
• PaaS Management Services (i.e. controllers, load balancer, metering, billing, and monitoring)
• Infrastructure as a Service (compute only)
• IT Administrative and Management

The Application Platform subscription component calculates the license, vendor maintenance, or subscription expense required to license access to application platform components.   The private Cloud scenarios listed in the worksheet utilize a straight yearly subscription fee per JVM instance.

PaaS Management Services load balance tenants across application platform nodes, monitor PaaS node health, collect metering information, and provision tenant environments.  As many ‘Private PaaS’ deployments replicate traditional application platform topology within the run-time environment, the worksheet removes PaaS Management Service cost from the traditional deployment template scenarios.  If your single tenant, dedicated deployment requires run-time management services (e.g. Cloud Foundry), adjust the worksheet accordingly.  The worksheet may understate the cost required to deploy Cloud Foundry and other single dedicated PaaS delivering on-demand, tenant-aware elastic load balancing.

Across all scenarios, the worksheet calculates cost when application platforms are deployed on Infrastructure as a Service (IaaS).  The worksheet IaaS compute benchmark cost from Amazon AWS EC2 calculator (as of 11 May 2012).  The projected spend is $659 per month for a High-Memory Double Extra Large Instance.

The IT Administrative and Management yearly cost item incorporates administration effort required to generate monthly chargeback/showback statements, configure tenants, monitor run-time environment per tenant, and up-front training investment.

Column B reflects the multi-tenant, shared container scenario.  Column C reflects a single tenant deployment, which is used as input to traditional deployment scenarios (Column D-G).  The traditional deployment scenarios replicate single, dedicated tenant silos in a PaaS environment.   A dedicated tenant silo shares IaaS across JVMs, and dedicates running JVM instances to specific tenants.

Calculation Variables

The following variables may be changed to evaluate cost within your specific context:

• Number of tenants
• Tenant density per JVM [applied per Application Platform Service]
• License instances (i.e. Java Virtual Machine instances or servers) per Application Platform Service and PaaS Management Service
• Java Virtual Machine (JVM) density per IaaS Node
• Cost per IaaS Node

IaaS compute instance size (e.g. small, medium, large) and application platform footprint (i.e. 256MB, 2GB, 4GB) will influence JVM density per IaaS node.  The worksheet assumes a 32GB IaaS compute instance node with 4GB allocated to each Java Virtual Machine.  The worksheet projects an expected JVM density of 8 JVMs per IaaS node.  The worksheet user may adjust the number of JVMs per IaaS node.

Tenant isolation, partitioning strategies, and service performance will influence tenant density per JVM.  The worksheet’s projected Application Platform Service JVM count considers redundancy, failover, expected load, throughput, and service performance.  The JVM count will typically vary based on hosted Application Platform Service type, throughput, and expected load.  For example, an Identity Management service can often accommodate a greater number of tenants compared with an Enterprise Service bus service.   The tenant density per JVM will vary based on vendor product and workload profile.  In the single tenant scenarios, a single tenant is mapped per dedicated JVM or JVM cluster.  In the multi-tenant shared container scenario, a JVM instance uses OSGI partitioning, tenant specific resource context, and on-demand tenant artifact loading to share JVM resources while maintaining Quality of Service, performance, and security.   In a multi-tenant shared JVM scenario, the worksheet specifies a maximum of seven (7) tenants per JVM in high load situations (e.g. ESB, Application Server, Business Process Management).

Tenant density significantly impacts the number of IaaS nodes and licensed application platform servers.  In the default worksheet configuration, a single tenant per JVM yields a single tenant density of eight (8) tenants per IaaS node.  In a multi-tenant shared JVM scenario, the worksheet specifies a maximum of seven (7) tenants per JVM and 42 tenants per IaaS node.

The worksheet uses a straight subscription support fee per JVM instance and IaaS compute benchmark cost from Amazon AWS EC2 calculator (as of 11 May 2012).  Worksheet users should adjust this number to reflect vendor specific license expense, maintenance expense, subscription investment amounts, and internal cost to deliver IaaS compute nodes.  As storage, network I/O, and external IP addresses will remain constant across all scenarios, the worksheet excludes these costs.

Modifying Cost Scenarios

To modify the cost scenarios and accurately model your expected cost savings from multi-tenant, shared container PaaS, you should collect the following load information:

• A specified number of tenant projects in Year 1,2,3
• Known tenant load (e.g. web requests, transactions, memory, CPU, latency)
• Known mapping between tenant load and service capacity

The information can be used to derive the following variable values:

• Expected number of tenants
• Number of Application Platform Service JVMs
• JVM density per IaaS node

Modify the worksheet to reflect your specific environment context. Cost variables are shown in ‘blue font’.

Bottom Line

In large-scale, multiple application service deployments (i.e. 100 tenants and 5 services), multi-tenant shared container PaaS is 14 times (14X, 1400%) more efficient than single container deployment when measuring number of JVM instances.  Positive financial TCO is achieved after sixteen (16) tenants subscribe to the environment.  After all 100 tenants have subscribed, the multi-tenant shared container PaaS is 659% more cost efficient than single container deployments. Table 1 illustrates the details.

In large-scale, single application service deployments (i.e. 100 tenants and 1 services), multi-tenant shared container PaaS is 13 times (13X, 1300%) more efficient than single container deployment when measuring number of JVM instances.  Positive financial TCO is achieved after twenty-two (22) tenants subscribe to the environment.  After all 100 tenants have subscribed, the multi-tenant shared container PaaS is 475% more cost efficient than single container deployments.  Table 2 illustrates the details.

In small-scale, multiple application service deployments (i.e. 8 tenants and 2 services), multi-tenant shared container PaaS is three times (3x, 300%) more efficient than single container deployment when measuring number of JVM instances. Positive financial TCO is achieved after four (4) tenants subscribe to the environment.  After all eight (8) tenants have subscribed, the multi-tenant shared container PaaS is 214% more cost efficient than single container deployments.  Table 3 illustrates the details.

In small-scale, single application service deployments (i.e. 8 tenants and 1 service), multi-tenant shared container PaaS is two times (2.2x, 220%) more efficient than single container deployment when measuring number of JVM instances. Positive financial TCO is achieved after five (5) tenants subscribe to the environment.  After all eight (8) tenants have subscribed, the multi-tenant shared container PaaS is 166% more cost efficient than single container deployments.  Table 4 illustrates the details.

Table 1: High scale, multiple application service deployment

Table 2: High scale, single application service deployment

Table 3: Small scale, multiple application service deployment

Table 4: Small scale, single application service deployment

John advises IT groups to:

“approach Progress as a specialist vendor with three distinct products, not an enterprise platform provider. Progress has good products, but clients must include in their evaluations of those products the continuing business execution risk that the company will face during the next year. Progress is still in transition.”

I’m not quite sure what type of IT infrastructure provider Progress will be after the transition.  Neil Ward-Dutton reviewed Progress’ strategy and decrees:

“if we take this at face value (and that’s all I can do at this stage) that means no more technology to support customers looking to implement BPM, SOA, or MDM.”

In contrast, WSO2 is a 100% open enterprise platform provider with a dedicated focus on delivering a complete, composable, and cohesive middleware platform spanning data to screen.   Our WSO2 Enterprise Platform enables SOA, BPM, API management, web application development, and Cloud.

Our WSO2 ESB, WSO2 Governance Registry, WSO2 Business Activity Monitor, and WSO2 Identity Server provide a production proven, high performance SOA middleware foundation.   We welcome you review our case studies and learn how WSO2 ESB processes more than 1 billion transactions per day for eBay, streamlines the development and maintenance of smart power grids, supports T24 core banking systems, and enables consolidated reporting across enterprise applications.  I have created an ESB evaluation framework which may assist your vendor selection.

Our Platform as a Service offering, WSO2 Stratos, delivers 13 middleware services (i.e. application server, mashup server, gadget server, business process server, business rules server, business activity monitoring, complex event processing, enterprise service bus, governance registry, identity management, data services server, relational storage service, Cassandra storage server) in a multi-tenant, on-demand form factor.  IT organizations may deploy WSO2 Stratos in an on-premise private cloud, on Amazon AWS, or through Cloud PaaS providers.

Our Offer to Progress Sonic ESB and Progress FuseSource Customers

WSO2 desires to assist Progress Sonic ESB and Progress FuseSource customers choose a viable, stable, and supported middleware platform.  We are offering free Evaluation Support to current Progress Sonic ESB and Progress FuseSource customers, and would be pleased to demonstrate how our market leading WSO2 Enterprise Service Bus and WSO2 SOA Platform meets your evaluation criteria.  Feel free to contact us via our contact form or send us an email note.

Case Studies

eBay uses 100% open source WSO2 ESB to process more than 1 billion transactions per day

eBay is the world’s largest online marketplace. WSO2 ESB helps to ensure high performance and 24×7 availability during peak holiday shopping season.

WSO2 ESB-Enabled Integration and Mediation Energize Smart Power Grids

Read how Dongfang Electronics Co. Ltd., one of the largest electric power automation system manufacturers in China, is using the open source WSO2 Enterprise Service Bus (WSO2 ESB) to streamline the development and maintenance of smart power grids

WSO2 Middleware Ensures Alfa-Bank a Promising Future in SOA

The WSO2 Application Server together with the WSO2 ESB has enabled Alfa-Bank to implement seamless integration of the T24 core banking system with its existing internal and third party systems

Concur Streamlines Corporate Reporting With WSO2 Open Source SOA Middleware

This case study highlights how one customer successfully implemented a SOA initiative to deliver consolidated reporting from enterprise applications distributed across multiple systems.

While many Linux distributions include a basic application server, Linux by itself does not deliver a complete application platform.   At a minimum, development teams commonly layer WebSphere, JBoss, Tomcat, or WSO2 Carbon Application servers on top of Linux.  VMWare Cloud Foundry’s open architecture will front-end any application server through their Droplet Execution Agent (DEA) architecture (after integration work is performed!).  Derek Collison has authored material describing the ability to plug-in third-party application servers.  The level of integration between Cloud Foundry’s framework and the application platform will differentiate offerings.

VMWare’s recent announcement equating VMWare Cloud Foundry with Linux demonstrates an operating system focused mindset, and does not address the environment required for developing enterprise applications.  As mentioned by the Cloud Foundry team, most of their work is below the waterline and does not directly address innovation relevant to application developers.

As to whether Cloud Foundry is a cloud operating system or capable of building vendor-neutral clouds, I defer to Charles Babcock’s article and your experience.  Is your team building an application server agnostic Platform as a Service environment on top of Cloud Foundry?   What limitations do you experience when wrapping traditional application server clusters with a PaaS framework (e.g. VMWare Cloud Foundry)?

My colleague Gary Hein once mentioned, “It seems there are only 500 guys in IT that you constantly run across.”  Over the past four years, I have formed a relationship with Sinclair Schuller, Apprenda’s CEO.  Sinclair has been recently turning up the marketing amp and conveying the benefits/drawbacks of private and public cloud.  Sinclair’s views can be found in an article recently published on CIO.com and a VMBlog Q&A session.  Both the article and Q&A session are worthy reads.  If you enjoy watching videos, I have created a Cloud dimension video with Jonathan Marsh.

As a fellow private cloud arms dealer, I am pleased Sinclair promotes Platform as a Service and private use cases. According to the CIO.com article,

“Private PaaS is the deployment of a PaaS software layer on an enterprise’s internal infrastructure with the goal of exposing the PaaS service to the developers within an enterprise’s various lines of business.”

While the statement is accurate, I wish Sinclair had expounded on the value derived from using PaaS hosted on private external Clouds.  Public/private and internal/external are two separate dimensions.  Public, private, or community attributes specify how widely the cloud service is shared; a sharing dimension.  Internal or external denote the consumer’s view of the Cloud’s service interface.  The view is associated with a consumer’s responsibility for service development, operations, and management; a responsibility dimension.  A third dimension, on-premise or outsourced, describes where the service assets are located; a location dimension.  Many architects conflate the three dimensions. NIST has recently published a Cloud Computing Reference Architecture which spends considerable prose disentangling the concepts.  According to NIST,

“A private cloud gives a single Cloud Consumer‟s organization the exclusive access to and usage of the infrastructure and computational resources. It may be managed either by the Cloud Consumer organization or by a third party, and may be hosted on the organization‟s premises (i.e. on-site private clouds) or outsourced to a hosting company (i.e. outsourced private clouds).”

Let’s run through three quick use cases describing public, private, and community:

1. A public cloud service is accessible to any consumer.  For example, all organizations who have sales teams.
2. A private cloud service is accessible to only members of a single team. For example, a custom tailored Enterprise Resource Planning application delivered as a service to company employees.
3. A community cloud blends the two access models. A community cloud service is accessible to a select, exclusive group. For example, a classified information service delivered to government agencies

A person or organization will often use and deliver cloud services across private, public, and community environment.  A hybrid cloud strategy delivers, spans, and connects clouds across all dimension attributes.  According to NIST,

“A hybrid cloud is a composition of two or more clouds (on-site private, on-site community, off-site private, off-site community or public) that remain as distinct entities but are bound together by standardized or proprietary technology that enables data and application portability.”

To effectively implement a hybrid cloud, the solution must exhibit interoperability and policy federation across cloud services.  Interoperability and federation are two difficult to implement concepts. Teams should choose technologies such as XACML, OAuth, SAML, JSON, RESTful interfaces.  Cloud blending using technologies alone is often difficult.  Infrastructure products and services such as WSO2 Stratos Identity as a Service, WSO2 Stratos Governance as a Service, and WSO2 Stratos Data as a Service can assist the distillation process (see Figure 1)

Figure 1. WSO2 Stratos Platform as a Service

New Cloudy infrastructure is often required to build internal clouds.  When you are the service provider, the cloud is internal to your team. Your team sees all the complexity, dependencies, and inner relationships. Internal clouds require your team to be experts in demand management, capacity management, resource monitoring, resource management, deployment automation, billing, and scalability tuning practices.  According to Sinclair,

“PaaS is a software layer that typically stitches together networked resources including OS instances, database server instances, web server instances, and even load balancers into a single, shared logical hosting layer. Essentially, PaaS is best summarized as a data center OS.”

Private PaaS infrastructure attempts to turn your team into a data center OS service consumer.  Your team should only sees a simple, easy to use service interface (see Figure 2).

Figure 2: Encapsulating capabilities behind a simple, easy to use service interface

Encapsulating a capability within a service

The service interface hides complex technology and processes required to deliver an elastic and scalable cloud on shared resources.  However, if the service interface is leaky, you must still contend with complexity (see Figure 3).

Figure 3: Example complexity exposed by Leaky PaaS

A PaaS Leaking Complex Infrastructure Details

We find certain Paas offerings both hide complexity and provide a solid, easy to use service interface, or they provide a difficult to use leaky service interface.  A leaky PaaS service interface:

• Exposes machine host names instead of URLs
• Specifies confining Java Virtual Machine memory configuration limits instead of delivering an elastic and scalable memory pool
• Requires server reboots to scale compute clusters
• Exposes tenants to security and Quality of Service risk

A leaky PaaS service interface requires developers to

• Download and install application platform modules instead of subscribing to application platform services
• Modify load balancer tables instead of specifying service policy
• Deploy applications via system administration console commands

Our strategic goal at WSO2 is to deliver on-premise Cloud middleware and outsourced Cloud middleware services that enable your development teams to more effectively design, develop, deploy, and manage your applications.  Your development teams should not care about network routing, machine counts and size, Java Virtual Machine configurations, or clustering protocols.  Your teams are free to focus on provisioning services, declaring policies, defining registry spaces, and building/enhancing business domain capabilities.   During my strategy call with Paul Fremantle, co-founder and CTO of WSO2, Paul mentioned a strategic focus to deliver a SLA based offering (rather than an infrastructure based offering) delivering tiered level of services and the ability for your teams to charge by transaction and business use rather than storate/network bytes and processing cycles.

Why do we care about public/private/community, internal/external, and on-premise/outsourced?  A Cloud service’s position on the dimensions directly impacts your responsibility and risk.

• Public/private/community impacts the provider’s ability to incorporate your requirements into the service. A private service can be extensively customized and delivered on your release schedule. A public service can only be configured and is often general purpose. While a community cloud often incorporates special purpose domain capabilities.
• Internal/external impacts your role and responsibility in maintaining the reliability, availability, scalability, and security of the cloud.  Are you an expert in data center operations?
• On-premise/outsourced impacts whether you are responsible for the assets. Do you want to own hardware?

Tread carefully when adopting PaaS today.  Use the location, ownership, and sharing dimensions as an architecture and product selection starting point.  Table 1 maps the three dimensions to common cloud terms and Figure 4 visually illustrates the differences.  A table or visual of ‘1’ indicates ‘Low’ or ‘Near’.  For example, ‘low sharing’, ‘low responsibility’ or ‘near location’.  A table or visual value of ‘3’ indicates ‘High’ or ‘Far’.  For example, ‘high sharing’, ‘high responsibility’, or ‘far location’.

Table 1: Mapping sharing, location, and responsibility to Cloud dimensions

Figure 4: Visual representation of Cloud Dimensions

Cloud Dimension Kiviat

To determine where your projects fit within the dimensions, use the following roadmap:

• Determine goals and outcomes
• Define acceptable risk (Data sensitivity, QoS, requirements, schedule)
• Establish reasonable responsibilities for in-house team (operations, development, project management)
• Determine solution specialization requirements (platform stack, business processes, rules, data, complex event processing, data)

After you determine your requirements and fit within Cloud dimensions, create a matrix to evaluate Platform as a Service offerings.  Because most individuals and organizations will require services landing across multiple landscape positions, investing in PaaS offerings that span public/private/community, internal/external, and on-premise/outsourced is desirable.   WSO2′s Carbon Enterprise Application Platform uniquely spans all environments (See Figure 5).

Figure 5: WSO2′s PaaS Deployment Choices

on-premise private PaaS, public cloud, and on-premise terrestrial

Beware of false clouds or cloud washed platforms as defined by Frank Scavo, Founder, President @ Strativa, in his blog post.  I have created a Platform as a Service Evaluation Framework to help you identify the Cloudiness quotient of your PaaS.

Integration teams use ESBs to solve service-oriented anti-patterns of isolation, uniqueness, and duplication.  Isolation refers to stand-alone system silos and point-to-point connections between systems (as opposed to shared connections).  Unique data schema models for similar entities, transactions, and processes raise integration cost.  When an organization fields multiple software applications delivering similar business functions and requires redundant data entry, opportunities exist to remove duplication and save both operational expense and maintenance cost.

To reduce service-oriented anti-patterns, teams desire to share and re-use assets, consolidate functionality, and conform projects to common standards.   To achieve these best practices, teams rely on an ESB to deliver the following required architectural attributes:

• Interoperability
• Abstraction
• Resource location virtualization
• Ability to scale and manage service
• Declarative policies and platform independent models
• Separation of concern
• Loose coupling

Architectural attributes are hard to measure, and we find most evaluation teams do not develop evaluation use cases across all architectural attributes.  Teams often focus on easy identifiable product features.  ESB products may contain the following required and optional features:

Required features

• Routing
• Protocol bridging
• Message transformation
• Service agent hosting

Optional features

• Resource adapters
• Composition
• Orchestration
• Reliable message delivery
• Event processing
• Transactional integrity
• Message Exchange Pattern (MEP) mediation
• Dynamic location and binding, load balancing
• Message validation
• Capability mediation
• Security mediation (federation)
• Tooling

After creating use cases testing an ESB’s ability to deliver architectural attributes and features, an ESB evaluation process should also consider how the ESB fits into the complete platform.  An ESB is usually just a single component in a broader composite SOA Platform.   Teams often combine an ESB with Governance Registries, Identity Servers, Business Activity Monitoring, Complex Event Processing, and Business Process Management.  Teams often differentiate ESBs based on how well the ESB fits into a complete solution.  A platform built by vendor innovation instead of vendor acquisition will often provide a more holistic and cohesive experience by sharing meta-data, administration consoles, programming models, and foundational features (i.e. logging, security, management, provisioning).

Performance, scalability, and topology strongly influence solution agility and adaptability.  We see organizations evaluating how well ESB candidate products fit across hybrid Cloud environments (i.e. on-premise, outsourced, internally managed, externally managed [1]), high transaction loads, and low latency use cases.  Teams should devote ample time to build suitable performance, scalability, and topology tests.

A Proof of Concept project provides an opportunity to ‘kick the tires’ and evaluate the ESB’s ability to satisfy use cases.   Rather than simply relying on vendor demos, download the bits and directly experience the ESB’s programming model, administration interfaces, documentation, and samples.   During the Proof of Concept project, carefully evaluate the vendor’s support processes, openness [2], responsiveness, and ability to recommend suitable solutions.

By carefully considering your requirements, constraints, and technology strategy, your team can build an ESB evaluation framework demonstrating product similarities and strategic differences.  A comprehensive, weighted evaluation criteria set will ensure the ESB meets your needs today and in the future.  An evaluation framework mindmap is shown below:

Enterprise Service Bus Evaluation Framework

[1] http://blog.cobia.net/cobiacomm/2011/11/07/know-your-cloud-dimensions/

[2] http://blog.cobia.net/cobiacomm/2012/03/14/value-openness/

1. Share infrastructure and improve internal software delivery
2. Enable on-demand digital disruption via ecosystem platforms

Share infrastructure and improve internal software delivery

Development teams desire to increase efficiency by sharing infrastructure and improving software delivery.  WSO2 Stratos delivers seventeen distinct on-demand middleware services.  Cloud tenants may subscribe to WSO2 Stratos’ multi-tenant shared services and eliminate traditional application platform provisioning time lag.

Teams desire to enhance agile development methodologies by integrating DevOps practices and on-demand application life-cycle infrastructure. Teams often are burdened by a need to provision a complex set of project tracking, source code management, issue tracking, test tools, release management scripts, and run-time application platform environments (i.e. development, test, production).  WSO2 AppFactory applies on-demand self-service and automated provisioning patterns to software projects.  The WSO2 AppFactory environment delivers multi-project software delivery infrastructure tools and encourages software delivery best practices. WSO2 AppFactory enable teams to create and administer projects, automatically build applications, provision quality assurance environments, run continuous integration tests, and continuously promote and deploy software assets across development life-cycle environments (i.e. Development, Test, and Production).  Figure 1 provides a visual illustration.

WSO2 AppFactory

Enable on-demand digital disruption via ecosystem platform

Technology consumerization, capability externalization, and content creation/sharing democratization are disrupting traditional business models [1,2].  Startups and upstarts are rapidly disinter-mediating and replacing brand-name business providers, brokers, and distributors.  Business leaders are realizing new digital strategies are required to build relevance and connections across their suppliers, customers, and employees.

A new application platform environment is required to increase IT interaction efficiency, deliver composite business service offerings, and enable new revenue sharing opportunities.  Our clients augment WSO2’s Cloud Native application platform, WSO2 Stratos, with shared business capabilities, custom showback/chargeback models, and application hosting to create an AppFactory delivering digital disruption to internal IT delivery. We have productized the digital disruption and ecosystem patterns in our WSO2 AppFactory offering.

An ecosystem platform helps organizations extend their core business capabilities across application projects.  A multi-tenant, extensible cloud environment is used to personalize channel interactions and deeply embed business capabilities within a business partner’s distribution channel (similar to Force.com, eBay sellers, or Amazon Store environments).  By natively including on-demand self-service and automated provisioning, the platform enables efficient engagement with ad hoc departmental and line of business projects (i.e. the long tail) and ability to quickly scale.  By hosting all application projects within a multi-tenant environment, the environment can easily aggregate and share business information.

[1] http://mashable.com/2011/10/27/digital-disruptors/

[2] http://socialmediatoday.com/david-h-deans/469985/sxsw-2012-digital-disruption-continuum

“When the API is available, Adam Ludwin at RRE, says he’s interested in entrepreneurs who can build on top of the platform, who can “close the loop” and figure out a way to monetize the interest around products on Pinterest. He’s interested in startups that will provide tools to facilitate transactions on and through Pinterest.”

But exposing an API can lead other companies capturing revenue otherwise directed to Pinterest.  As reported recently by Jay Yarow, Pinterest

“might not release it [API] for a while, says an industry source familiar with Pinterest’s plans. This source says that Pinterest fears having a ‘Twitter problem.’”

What is the Twitter problem?

Twitter, the widely successful ‘open data’ messaging company, recently encountered head-on conflict with its ecosystem partners.   Twitter’s open API and liberal terms of service yielded numerous ‘partnering’ organizations, who extended Twitter and made the basic service more usable through 3rd party applications.  The problem for Twitter?  Twitter didn’t have mechanisms in place to monetize their user base, had their customer ownership diluted, and the company increasingly saw external companies making money from their extensions.  The solution, Twitter embarked on a costly and time consuming defensive strategy to buy Twitter clients, locked down access to their API, and disenfranchised the 3^rd party developer community.

Om Malik of GigaOm rightly points out that the Twitter’s easy access policies were based on not defining their business model and then making appropriate decisions.  Had Twitter been aware of its options and consequences from the early days, they may have defined a clearer ecosystem strategy. For example, Om states

“If Twitter at some point thought of itself as a media network, then its business model option would have included controlling the front end(s) to the service. Instead, it didn’t do any of those things. One logical explanation is that the service itself was evolving as it went along.”

While Pinterest is playing smart by moving cautiously, how should Pinterest effectively monetize user interest and create an engaging ecosystem?

An Ecosystem Platform Recommendation for Pinterest

With data APIs, users are always one step removed from the platform company. Intermediary applications (between the data provider and end user) have the opportunity to reshape the customer relationship.  Rather than rely solely on data APIs, we have seen forward-thinking organizations create ecosystem platforms revolving around user experience APIs and domain specific hosting environments. With user experience APIs, the platform company can create an ‘Apple experience’; maintaining customer ownership by controlling the ‘look and feel’ and by authorizing third party extensions.  Add in a 3^rd party application hosting environment‘ (similar to SalesForce.com), and the ecosystem platform can manage Quality of Service (QoS), share monetization revenue, and enforce compliance regulations (e.g. PCI Security Standards, HIPAA, European Union Directive on Data Protection of 1995).

Instead of simply publishing data APIs, Pinterest could manage and host 3^rd party applications within a multi-tenant cloud ecosystem platform.  WSO2 clients are using WSO2 API Management and WSO2 AppFactory, a cloud ecosystem platform, to deploy context-aware APIs, rapidly provision 3^rd party application projects, automate governance approval tasks, ensure regulatory compliance, monetize user interactions, and host applications that seamlessly extend the user experience.

The ecosystem platform environment also provides an opportunity for Pinterest’s partners to deeply embed their business capabilities within Pinterest’s application (similar to Force.com, eBay sellers, or Amazon Store environments).  By hosting all business partners as tenant applications within a multi-tenant environment, the ecosystem environment more readily aggregate and share business information.  Figure 3 illustrates how a complete middleware platform, API management, and Platform as a Service can be composed as an ecosystem platform.

Bottom Line

Pinterest is playing smart by moving cautiously and fully evaluating business models and core features before opening up their platform.  To effectively monetize user interest and create an engaging ecosystem, we recommend Pinterest create ecosystem platforms revolving around user experience APIs and a domain specific hosting environment.  WSO2 AppFactory, a cloud ecosystem platform, will enable Pinterest to deploy context-aware APIs, rapidly provision 3^rd party application projects, automate governance approval tasks, ensure regulatory compliance, monetize user interactions, and host 3^rd party applications that seamlessly extend the user experience.

Related Posts and References

WSO2 API Management Platform

APIs and Beyond

Creating and Ecosystem Platform with Vertical PaaS

• There was no straightforward means to facilitate communication between the mobile application and AAA’s services and data storage layers.
• There was a need for better means of accessing and reusing existing services
• There was a need to ensure flexibility in business rules without the need to continually redeploy the application.

Join Jordan Corn, Director of Solutions Research and Ed Klichinsky, Solutions Architect at AAA along with Asanka Abeysinghe, Director Solutions Architecture and Miyuru Wanninayaka, Senior Software Engineer at WSO2 as they discuss the implementation of a communication path between a mobile app (specifically an iPhone app) and AAA Mid-Atlantic. The session will commence with an introduction of the challenges faced by AAA in the advancement of the mobile app. This will be followed by a detailed discussion of how the WSO2 Mobile Services Gateway was successful in overcoming these challenges.

The recorded webinar presentation and associated slide deck can be found on the WSO2 Webinar archive page.

It’s intent is to reduce the cost and complexity of user management operations and provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. SCIM delivers more agile integration with Google Apps, Salesforce and other SaaS providers.

At a recent IETF meeting, WSO2, Sailpoint, Ping Identity, UnboundId, Cisco, Technology Nexus, SalesForce, Gluu, Curion, and BCPSoft performed interoperability testing.  The twenty-one SCIM interop use cases covered managing users and groups.  During the interop event, WSO2 Charon, WSO2′s SCIM implementation delivered under the Apache 2.0 license, performed well.  Interoperability testing uncovered a few areas where the specification requires clarification.

During the summer timeframe,  WSO2 will incorporate SCIM into the WSO2 Identity Server, a highly interoperable identity management platform.   WSO2 Identity Server delivers:

• Single Sign-On (SSO) via OpenID, SAML2 and Kerberos KDC
• Provisioning via SCIM instead of legacy SPML
• Auditing via XDAS
• Delegation via OAuth 1.0a, OAuth 2.0 and WS-Trust
• Federation via OpenID, SAML2 and WS-Trust STS
• Integration with Microsoft SharePoint with Passive STS support
• Implement REST security with OAuth 2.0 and XACML
• Attribute or Claim based access control via XACML, WS-Trust, OpenID and claim management
• Fine-grained policy based access control via XACML

Let me know if you would like a demonstration of the only complete open identity management server based on:

1. Open Architecture
2. Open Standards
3. Open License
4. Open Source

Traditional SOA and integration platforms enable rapid development, but they provide little business partnership support.  Teams commonly operate independently and autonomously.   Hundreds of people write new APIs and services; few people know:

• who is consuming APIs and services,
• who is writing re-usable APIs and services, or
• how APIs and services are being used.

UPDATE
View the product Page  |  Download the latest Milestone bits |  File enhancement requests

In order to overcome common SOA anti-patterns, teams must improve cross-team (or cross-partner) communication, coordination and collaboration.  Teams should extend their governance effort and offer managed APIs through an API Store.  A managed API is:

• Actively advertised and subscribe-able
• Available with an associated, published service-level agreement (SLA)
• Secured, authenticated, authorized and protected
• Monitored and monetized with analytics

An API Store is a venue to find, explore, subscribe and evaluate available resources.  The API Store enables partners to quickly find relevant APIs.  Once a candidate list is identified, the API Store provides a structured environment for exploring the APIs and understanding solution fit.   During the exploration phase, collaboration between the potential API consumer and provider is essential.  After finding and exploring an API, a project may stall when the team attempts to gain access.  An API store provides on-demand self-service subscription and collaboration channels, rapidly reducing the time and effort required to integrate and evaluate available API resources. Figure 1 illustrates API consumer lifecycle activities.

API Consumer Lifecycle Activities

Figure 1: API Consumer Lifecycle Activities

When selecting APIs, trust is an important consideration.  Without trust, potential business partners will choose other alternatives or build their own solution.  Team leaders must establish an environment where their team is the trusted provider of choice.  When teams follow best practices, potential partners recognize competency and reduce their adoption trepidation.

Establishing a separation of concerns between API provider and API manager responsibilities encourages competency.  An API provider is responsible for building, publishing, scaling and versioning the API.  The API manager is focused on promoting and encouraging potential consumers to adopt the API.   The manager analyzes usage patterns and determines how to best monetize the asset.  A monetization strategy solve a perennial IT questions:

• “Once I offer an API, what should be the show-back, charge-back mechanism?”
• “How do I actually perform investment re-capture activities?”

Figure 2 diagrams API lifecycle best practices for API providers and API managers.

Best Practices for API Providers and API Managers

Figure 2: API Lifecycle Best Practices for API Providers and API Managers

WSO2 has begun recruiting beta customers for the new WSO2 API Manager product scheduled to launch this summer.  Ideal candidates for the WSO2 API Manager beta program are enterprise IT professionals who are planning or evaluating infrastructure to offer APIs to third parties—whether externally or within the organization. WSO2 requests participant commitment to provide use cases and feedback. For more information please visit the product Web site at http://wso2.com/products/api-manager and contact us at mailto:bizdev@wso2.com to join the beta program.

WSO2 API Manager will enable enterprises to extend their data, processes and services out to customers, partners and other business units via APIs while providing the ability to secure, protect and monitor API resource interactions. WSO2 API Manager also will enable developers to rapidly find, subscribe to, and evaluate the APIs that enterprises make available.  Using WSO2 API Manager, enterprises will be able to:

• Offer APIs to their customers and partners, as well as other internal users.
• Display and promote APIs in an API store
• Enable developers to sign up and subscribe to APIs.
• Collect usage, performance, and quality of service metrics to analyze and understand how APIs are being used.
• Use a policy-based approach to securing APIs, managing access, and throttling usage.

Re-invent your software delivery and re-invigorate your SOA initiative by adding WSO2 API Manager and encouraging API adoption.

Additional Resources:

WSO2 API Manager Product Page

API & Beyond Webinar

How to build, manage, and promote APIs Webinar

Openness is multi-dimensional:

I’m not quite sure historical purchasing trends support the theory.

What structural change has occurred, which invalidates previous purchasing patterns and vendor actions? Throughout the history of compute, hipster languages and frameworks always exist; some die, some flourish. Language selection occurs at a micro-level, project by project. Vendor product (or PaaS service) has traditionally occurred at a micro-level as well (e.g. project by project, business unit by business unit, team by team).

History does not support the ‘One PaaS to Rule them All’ theory. True, PaaS environments supporting a greater number of languages may ease adoption by a greater number of developers, but the theory is untested. Microsoft .NET supports more languages. Do you see C++ and Java developers rushing to adopt the Polyglot CLR? Do you see rapid adoption of Mono in non-Windows environments? Decisions are often based on deep technical integration and a multitude of factors (i.e. performance, cost, technology standards, usability, interoperability, integration, capabilities).

What structural change impacts Polyglot PaaS adoption in a different manner, and is PaaS vendor focus on capturing a polyglot ecosystem an appropriate growth strategy?

The ‘it’s all about the ecosystem’ has historical merit (e.g. Windows, Android, Java, Facebook, iTunes). The defining attribute across the three first examples is NOT supporting ALL/many languages. The defining attribute across successful ecosystem offerings is an open architecture enabling an ecosystem of partners to extend the base platform with third party hardware, manufacturers, frameworks, apps, or music. The extensions enhance the platforms offering in a manner not offered by competitors.

Cloud Foundry has the correct strategy here; build a lightweight framework, which can be extended to run any application server, in any language. Cloud Foundry is a lightweight Cloudy server management framework, which must be paired with a language container (i.e. CLR, JVM, PHP shell) to offer an application platform as a service.

The strategy works right now because Cloud Foundry (the open source project) is not a complete solution, and PaaS providers desire to ride the VMWare marketing train (and obtain the start/stop server functionality ‘for free’).  PaaS platform differentiation is a more nuanced situation. Every PaaS will eventually create an ecosystem delivering adequate components and tooling.

Differentiation will require tuning the offering to specific target markets (i.e. consumer, SMB, enterprise) and solving perennially challenging IT use cases. The market will determine winners first and foremost on ‘do you solve my pain’ rather than ‘do you support multiple languages’.

View the video explain How PaaS is changing application servers?

SOA portfolio review objectives include determining if the service design methodology, service contract boundaries, and service coupling minimize portfolio redundancy and duplication while maximizing adoption. Discrete tasks may evaluate:

1. Service contract boundaries and resultant impact on consumption and orchestration.
2. Coupling between service design, service description, proxy/stub code, and core business logic code to determine expected agility, development cost, and maintenance burden.
3. Service design guidelines, service contract definition and associated policies
4. Expected service consumption and orchestration.
5. Process used by developers to discover, gain access, evaluate, and integrate portfolio services .
6. How the team builds and deploys artifacts and how the team develops services.

1. Does the design allow for the accomplishing key goals such as: modularity, configurability, and flexibility. This should lead to consideration of principles like loose coupling, abstraction, granularity, interoperability, and separation of concerns.
2. Can service consumers readily discover relevant services, and can consumers easily understand how the service matches their functional and non-functional requirements
3. How can service design, service development guidelines, service governance, service management, and service storefronts increase service adoption and minimize redundancy

Client deliverables into the evaluation process may include:

Design Models

• Any existing high-level uses cases,  requirements, and descriptions for planned and existing service interfaces and service deployments
• Business process and business capability models
• Service models and interface descriptions
• Review code artifacts and Maven artifacts generated during the implementation

Development governance practices (i.e. application, integration, services)

• Service design guidelines
• Development tooling and frameworks
• Service implementation process, code artifacts, and Maven artifacts.

Service integration, deployment and release engineering guidelines (i.e. administration, monitoring, solution provisioning, API key management, security integration)

Run-time policy requirements and enforcement mechanisms

• Security policies (i.e. application, integration)
• Service level agreements
• Organizational structure (i.e.  IT departments, competency centers, team roles and responsibilities)

Service Portfolio Map

• Applications / Projects
• Services / API
• Business capabilities and business domain
• Usage
• Cost

SOA Portfolio Review recommendations should span the following workstreams:

• Strategy
• Governance
• Service Models
• Standards
• Development processes
• Organizational dynamics

Join me in New York City on February 22 for an ESB and Enterprise Integration Workshop

You can view what Forrester thinks about WSO2 ESB at the Q2 2011 Wave Page.

To learn more about the WSO2 ESB online,   goto our WSO2 ESB product home page.

Learn more in our Practical SOA and Enterprise Integration white paper.

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:

WSO2 Carbon / Stratos Application Platform

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.

IaaS delivers basic network, storage, and compute- processing capabilities as standardized, scalable service offerings. Example IaaS offerings include Amazon EC2/S3, Windows Azure VM Role, and RackSpace Cloud Servers). Software as a Service delivers business software capabilities (e.g. expense reporting, logistics, benefits enrollment) and information feeds as online web applications and web services. Pioneered in the early 2000’s, SaaS was used to by independent software vendors to efficiently deliver an application without requiring on-premise installation, remote updates, and cost prohibitive instance management. Platform as a Service is application middleware offered as a service to developers, integrators, and architects.

Infrastructure as a Service offers development team a bare-bones infrastructure environment, which requires adding middleware, application frameworks, and infrastructure services (i.e. identity, entitlement, application logging). IaaS encapsulates hardware complexity and applies operational best practices. Operation teams create IaaS Clouds by applying virtualization, automation, and standardization to hardware provisioning and allocation tasks. As teams look to apply provisioning and automation to the application platform, interest in DevOps has grown.

The DevOps movement creates a collaborative environment bridging development and operation team members. DevOps enables team members to jointly design, build, and deploy business application and service solutions. The environment closes the gap between business requirements, policies, available run- time resources, and solution development.

Development and operation teams use Platform as a Service to design, build, and deliver customized applications or information services. Instead of relying on standardized SaaS, teams using PaaS have more control over solution architecture, quality of service, user experience, data models, identity, integration, and business logic. PaaS offerings often support DevOp practices, which include self-service, automated provisioning, continuous integration, and continuous delivery.

Figure 1 illustrates the Platform as a Service space, which incorporates IaaS DevOps practices and increases solution customization options. IaaS could be considered an unfinished house requiring appliances, cabinetry, and fixtures. At the other spectrum extreme, SaaS offers a fully furnished dwelling with little customization. Even if purple dotted lime décor is not your personal style, a SaaS may require you to sit on the purple dotted lime green couch. Alternatively, a PaaS offers a finished house with an array of personalized furniture choices.

Figure 1. Relationship between Platform as a Service and other Cloud service layers

Because the industry broadly defines PaaS as the level above hardware infrastructure and below business applications, development teams do not commonly have clear comparison criteria to intelligently evaluate frameworks or determine adoption benefits. At a minimum, PaaS offerings differ from traditional application platforms by shielding teams from direct infrastructure ownership, management, and complexity. To maximize business benefit, PaaS offerings should significantly exhibit essential Cloud characteristics. The NIST Draft – Cloud Computing Synopsis and Recommendations defines Cloud characteristics as:

• On-demand self-service

• Broad network access

• Resource pooling

• Rapid elasticity

• Measured service

PaaS offerings will vary from cloud washed to cloud native. While cloud washed PaaS solutions will deliver familiar architecture and programming models, they will offer modest Cloud characteristic advancements and deliver only incremental improvement in your ability to meet user demand, rapidly deliver new capabilities, reduce time to market, and lower cost. Cloud native PaaS solutions will inject behavior into the application to decouple application code from run-time infrastructure details, increase application density, and facilitate distributed interactions. To determine whether a PaaS is cloud washed or cloud native, fully evaluate platform capabilities, attributes, and topology.

Cloud washed offerings are optimized for traditional, static single-tenant deployment. Single tenancy will force teams to provision a virtual instance for every client; consuming large amounts of machine resources (e.g. CPU, memory) and increasing administration effort. Cloud washed offerings exhibit elastic scale by provisioning (or de-provisioning) entire physical machines or virtual images, and manual effort is often required to synchronize application platform session state with hardware infrastructure changes.

Cloud washed solutions modify the architecture at the virtual machine and network level. The architecture simply adds hardware virtualization and application platform provisioning. Cloud washed solutions exhibit reference architecture models that closely correlate with those found in traditional, terrestrial on-premise environments. In a Cloud washed environment, application platform components (i.e. application server, enterprise service bus, business process management engine, identity store) are not re-factored to natively support cloud characteristics or supporting architectural attributes (i.e. tenancy, dynamic discovery).

Cloud’s roots reside in hardware infrastructure, IT operations, and web application delivery (i.e. SaaS). Many individuals believe PaaS benefits can be accrued without refactoring the application platform, and few vendors have delivered middleware supporting new application architecture and programming models, which facilitate cloud characteristics. As a result, PaaS offerings often recreate the traditional machine environment in the Cloud. The Cloud washed PaaS environments commonly do not shield application developers, integrators, and architects from infrastructure details (i.e. memory configuration, location, number of machine instances). While short-term benefit is derived by ‘quickly pushing bits into the Cloud’, the design and development experience remains the same.

To improve application and information service delivery, teams must transform the development experience. Cloud native solutions shield teams from infrastructure details and inject new behavior into the application. Cloud native solutions are natively multi-tenant, elastic, dynamically wired, and incrementally testable. The entire application platform stack spanning virtual machine, managed code container (e.g. Java Virtual Machine), application platform engines (e.g. business process engine, presentation engine, enterprise service bus, business activity monitor), and persistence should support multi-tenancy. Multi-tenancy enables teams to customize applications and services per consumer by changing run-time configuration settings instead of provisioning new instances. As user demand grows and shrinks, an elastic and distributed platform will right-size application resources based on utilization, quality of service, and cost optimization policies. When resources are added, subtracted, or moved, the automated service management components dynamically re-wire resource connections. To further increase business agility, the PaaS environment must enable rapid release iterations and incremental solution testing.

The Selecting a Cloud Platform White Paper describes PaaS evaluation criteria, capabilities, and attributes from an application architect’s perspective and architect’s desire to maximize Cloud characteristics while decoupling applications from infrastructure topology specifications.

I have posted a presentation Introducing Platform as a Service (PaaS)

Related posts:

Selecting Platform as a Service

PaaS Evaluation Framework for CIOs and Architects

How to simplify Platform as a Service Complexity

Searching for Cloud Reference Architecture

 “Let’s make this stuff as simple as possible, articulating complexity does much to build barriers to cloud adoption….”

With any new technology, complexity is often a significant barrier, and technology professionals must carefully balance promised benefits and adoption challenges.  Widely adopted technologies (e.g. web browsers, HTML, DHCP, SMTP, Windows, text messaging) crossed the chasm when they simplified the user’s experience.    For example, Dynamic Host Configuration Protocol (DHCP) simplifies the Internet Protocol address assignment and helped TCP/IP adoption by non-network savvy individuals.   Mozilla spurred Web adoption compared to the text-based Lynx browser.  Ben’s comment foreshadows Cloud’s future path forward; continue to simplify the user experience or be relegated to a niche offering.

Sam Johnston sums up the goal in a recent Cloud complexity blog post:

“consumers of cloud services should finally be enabled to apply information technology to business problems, without unnecessary complexity.”  Online web applications serving as a forward face of Software as a Service (SaaS); enabling consumers to solve business processes without extensive installation.  While virtual machines and Cloud machine pools, which underlie Infrastructure as a Service (IaaS), undoubtedly simplify the IT procurement cycle.”

However, as we further Cloudify IT infrastructure and IT processes, the inherent complexity of technology may start to leak into the consumer experience.  Sam warns:

“If you find yourself using complex terminology or unnecessary acronyms (e.g. anything ending with *aaS) then ask yourself if you’re not part of the problem rather than part of the solution.”

Platform as a Service (PaaS) attempts to simplify a complex optimization and configuration process for technology enamored consumers (i.e. developers and operators).   Developers and operators understand how complex interactions between technology components, user requirements, and consumer interaction patterns can make their job a success or failure.  As Cloud matures, the industry is considering whether PaaS can or should simplify the application platform.  James Urquhart opines:

“If you are looking to cloud computing to simplify your IT environment, I’m afraid I have bad news for you.”

Ofir Nachmani post, Cloud Complexity ? It’s a Wrench , seems to agree with a straightforward warning:

“I think many enterprises, in their best efforts to implement all that they are told they can’t do without, are heading for more complexity than they ever dreamed possible.”

But Ofir and James diverge on our ability to successfully manage complexity.  James seems to place his trust in Cloud as an adaptive system, which can be managed by mankind.

“All you can do is constantly monitor the success and effectiveness of the technologies you deploy into the cloud, and constantly tweak them to make them as useful as they can be in that environment.

It’s up to people to make technologies that survive cloud as a complex system—one component at a time. That’s, well, how you deal with it.”

 

Directly dealing with complexity is not particularly compelling, and while compiling this blog post, I connected the dots between Jame’s last sentence and Ben’s message of

“Let’s make this stuff as simple as possible.”

As organizations near the adoption chasm, an important question remains as to whether infrastructure tooling is simple enough to tame complexity.   Ofir provides a negative view:

“Today, there isn’t a CMBD tool on earth (yet) that can realistically and efficiently keep pace with the inherent fluidity, agility and flexibility of even the most well intended cloud deployments.”

 

The result is “shit will happen in the Cloud”… “when complexity is mixed with a lack of clear visibility.”

Sam Johnston promotes a positive perspective, which could potentially be construed as encouraging IT professionals to bury their head in the sand:

“We should be working to make cloud computing as approachable as possible, and drawing attention to its complexity does not further that aim.”

Have the vendors reached a point whereby best practice processes and technologies can “make complex topics simple” and minimize negative emergent behavior?  Is industry discussion about complexity required or desirable?  To encourage adoption, do we need to constrain Cloud use cases and focus on the simplified set?

I believe we do need to have a serious and honest conversation about complexity. The conversation must span our ability to minimize negative emergent behavior by defining architectural patterns (i.e. Actor model, REST, eventual consistency), abstractions (e.g. workspaces and channels instead of machines and memory), and technologies (like DHCP), which correct negative behavior and simplify the consumer’s experience.   We also need to promote viable Cloud use cases, and use cases where unmanaged complexity will lead to disillusionment.  In January 2012, my position is the Cloudification of most application servers does not simplify nor guard against negative outcomes.  As an example, consider the figure below.   Does your PaaS simplify application environment complexity by abstracting away hardware infrastructure and application platform details?

How does PaaS simplify the application platform experience?

• Can you integrate PaaS with your existing software development tooling and governance process?
• Can you implement consumer-provider interactions across a hybrid Cloud environment while maintaining quality of service?
• Can you decrease the number of configurations and standardize service offerings?

Many complex questions to answer this year and simplify the DevOps experience…..