Before Choosing, Know Your Cloud Dimensions

Summary:  Before selecting PaaS infrastructure, understand how sharing, location, and responsibility impact your public/private Cloud and internal/external Cloud decision.

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.