A New Way to Think about Cloud Service Models (Part 3)

ServiceSpectrum Logo

Part 3 – PaaS: A Spectrum of Services

In my previous post, I started developing the notion of a “universal” cloud service model that has IaaS is at one end and SaaS at the other of a spectrum. But spectrum of what?  I think it is the spectrum of services available from all cloud sources, distributed across a continuum of cloud service abstractions and the types of applications built upon them, as shown in the figure below.

Spectrum of Applications across Cloud Computing Service Models - Copyright (C) 2015 James Craig Lowery

This figure shows many cloud concepts in relation to each other.  The horizontal dimension of the chart represents the richness of the services consumed by applications: The further left an application or service appears in this dimension, then the more generic (i.e., closer to pure infrastructure) are the services being consumed.  Conversely, the further right, the more specific (i.e., more like a complete application) they are.

The vertical dimension captures the notion of the NIST IaaS/PaaS/SaaS triumvirate. The lower an app or service in this dimension, the more likely it is associated with IaaS, and the higher, the more likely SaaS.  Clearly, both the horizontal and vertical dimensions express the same concept using different terms, as emphasized by the representative applications falling along a straight line of positive slope.

In this interpretation, with far left and right or bottom and top being analogous to IaaS and SaaS, respectively, PaaS is left to represent everything in between.  Large-grained examples of the types of services that would fall into a PaaS category are shown along the Application Domain Specificity axis, anchored on the left by “Generic” (IaaS) and on the right by “Specific Application” (SaaS) on the right.

Traditional Datacenter Applications, shown in the lower left of the diagram, are simply typical “heavy” stacks of operating system, middleware, and application, and some persistent data stored in a logical physical machine form (usually a virtual machine). As previously mentioned, this type of application is the direct result of migrating legacy applications into the cloud using the familiar IaaS model, taking no advantage of richer services cloud providers offer.

Moving from left to right, the next less-generic (more-specific) type of services is the first PaaS-proper service most cloud adopters will encounter: structured data persistence. Indeed, most successful IaaS vendors have naturally grown “up the stack” into PaaS by providing content addressable storage, structured and unstructured table spaces, message queues, and the like.  At this level of abstraction, traditional datacenter applications have been refactored to use cloud-based persistence as a service, instead of managing disk files or communicating through non-network interfaces to database management systems.

The third typical stage of application evolution moving up and to the right is the Custom Cloud Application.  At this stage, the application is written using programming patterns that conform to best-practice cloud service consumption techniques.  Not only is cloud-based persistence used, it is exclusive – no other forms of persistence (storing something in a file in a VM, for example) is allowed. Although enterprise application server execution environments such as J2EE are usually incorporated into the architecture to create efficient common runtimes, it is when they are combined with network-delivered services for identity and optimization, and programming patterns that emphasize functional idempotence, that a new breed of highly available, reliable and scalable (even when backed by unreliable infrastructure) applications emerges.  Still, the logic comprising the core of the application is largely custom-built.

The fourth stage sees the heavy adoption of code reuse to create cloud applications.  Although the new model described in the previous paragraph still dictates the architecture, the majority of the code itself comes from elsewhere, specifically from open source.  The application programmer becomes more of a composition artist, skilled in his or her knowledge of what code already exists, how to source it, and how to integrate it with the bit of custom logic required to complete the application.

The fifth PaaS model, tantamount to SaaS, is the application that is composed from APIs.  This natural progression from the open source re-use case above keeps with the theme of composition, but replaces the reusable code with access to self-contained micro-services executing in their own contexts elsewhere on the internetwork. A micro-service can be thought of similarly as an object instance in classic Object Oriented Programming (OOP), except that this “object” is maximally loosely coupled from its clients: it could be running on a different machine with a different architecture, operating system, and written in any language. The only thing that matters is its interface, which is accessed via internet-based technologies.  Put another more succinct way, a micro-service is a domain-constrained set of functions presented by a low-profile executing entity though an IP-based API.

An example is an inventory service that knows how to CREATE a persistent CATALOG of things, ADD things to the catalog, LIST the catalog, and DELETE items from the catalog. This is similar in concept to generic object classes in OOP.  In fact, an object wrapper class is a natural choice in some situations to mediate access to the service.  The difference is that, instead of creating an application through the composition of cooperating objects in a shared run-time, we now create applications through the composition of cooperating micro-services in a shared networking environment.

One additional aspect of the figure upon which we should elaborate is the flux of qualitative values as one moves from point-to-point in this spectrum. The potential cost and ability to control the minute details of the infrastructure are maximized in the lower-left of the diagram. Clearly, if one is building atop generic infrastructure such as CPU, RAM, disk, and network interfaces, one has the most latitude (control) in how these will be used.  It should also be clear that in forgoing the large existing body of work that abstracts these generic resources into services more directly compatible with programming objects, and eschewing the benefits of shared multi-tenant architectures, one will likely pay more than is necessary to achieve the objective.  Conversely, as one gives up control and moves to the upper right of the diagram, the capability to quickly deliver solutions (i.e., applications) of immediate or near-term value becomes greater, and the programmer and operational teams are further spared many of the repetitive and mundane tasks associated with optimization and scaling.

Summary

So, that’s my take on cloud service models.  There’s really only one: PaaS. It’s the unifying concept that fits the general problem cloud can ultimately address.  But my concept of PaaS differs from traditional notions embodied in things like Cloud Foundry, OpenShift, and the like.  Those are but a small slice of the entire spectrum, and the “platform” is much more limited in scope than the view of the entire Internet and its plethora of services as the “platform.”  In a multi-cloud world, where we need the ability to use services from many sources and change our selections at any time due to our need or their availability, this is the only definition that makes sense.

This entry was posted in Cloud Computing Technology Insights. Bookmark the permalink.