Cloud Native PaaS run-time environments 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

How do these characteristics influence run-time behavior and determine whether PaaS offerings are cloud washed or cloud native?

Measured service or pay per use

The first Cloud characteristic, measured service, enables pay-as-you-go consumption models and subscription to metered services.   Resource usage is monitored, and the system generates bills based on a charging model.  To close the perception gap between business end-users and IT teams, the Cloud solution should bill for business value or business metrics instead of billing for IT resources.  Business end-users do not easily correlate business value with an invoice for CPU time, network I/O, or data storage bytes.  In contrast, business focused IT teams communicate value and charges based on number of users, processed forms, received marketing pieces, or sales transactions.  A cloud native PaaS supports monitoring, metering, and billing based on business oriented entities.

Rapid Elasticity

A stateful monolithic application server cluster connected to a relational database does not efficiently scale with rapid elastically.  Dynamic discoverability and rapid provisioning can instantiate processing and message nodes across a flexible and distributed topology.  Applications exposing stateless services (or where state is transparently cached and available to instances) will seamlessly expand and contract to execute on available resources.  A cloud native PaaS will interoperate with cloud management components to coordinate spinning up and tearing down instances based on user, message, and business transaction load in addition to raw infrastructure load (i.e. CPU and memory utilization).

Resource Pooling

Development and operation teams are familiar with resource pooling.  Platform environments commonly pool memory, code libraries, database connections, and resource bundles for use across multiple requests or application instances.  But because hardware isolation has traditionally been required to enforce quality of service and security, hardware resource utilization has traditionally been extremely low (~5-15%).  While virtualization is often used to increase application-machine density and raise machine utilization, virtualization efforts often result in only (~50-60%) utilization.  With PaaS level multi-tenancy, deterministic performance, and application container level isolation, an organization could possible shrink it’s hardware footprint by half.  Sophisticated PaaS environments allocate resources and limit usage based on policy and context.   The environment may limit usage by throttling messages, time slicing resource execution, or queuing demand.

Integration and SOA run-time infrastructure delivers effective resource pools.  As teams start to pool resources beyond a single Cloud environment, integration is required to merge disparate identities, entitlements, policies, and resource models.  As teams start to deliver application capabilities as Cloud services, a policy aware SOA run-time infrastructure pools service instances, manages service instance lifecycle, and mediates access.

On-demand self-service

On-demand self-service requires infrastructure automation to flexibly assign workloads and decrease provisioning periods.  If teams excessively customize an environment, they will increase time to market, lower resource pooling, and create a complex environment, which is difficult to manage and maintain.  Users should predominantly subscribe to standard platform service offerings, and your team should minimize exceptions.  Cloud governance is an important Cloud strategy compon