Nov 29, 2011 by Sinclair Schuller
Platform as a service (PaaS) has been hijacked. PaaS was supposed to be a critical bulwark in protecting cloud computing from the frail models of earlier computing eras, but to many, has become a category to dump anything that is tooling to help with some part of managing and deploying applications on cloud infrastructure. It will take some time to explain, hence the long post. I started thinking about this after reading posts by two cloud evangelists for whom I have tremendous respect and were venting their frustrations with the PaaS space – Krishnan Subramanian and Ben Kepes. Each published posts titled “AppFog Announces Java Support – What The Heck Is Happening In PaaS Space?” and “OpenLogic Announces General Availability of CloudSwing PaaS“, respectively, that delivered well-deserved jabs at the PaaS space. Why were the jabs “well deserved”? Because PaaS is littered with “me too” undifferentiated offerings that focus on “user experience” and “deploying apps”, that’s why. I’m less interested in understanding or claiming that a given vendor suffers from this, but more interested in the discussion of these issues in PaaS at broad. To understand this sentiment, we need to really spend some time to define what PaaS should be and what sort of trap the market is falling into.
To define PaaS, let’s first define an arbitrary collection of “traditional” Operating System (OS) instances on real or emulated hardware and any networking equipment associated with those OS instances as a resource pool. A PaaS’ can be best thought of as a computing platform that acts as a host to “guest” applications and that is layered atop a resource pool such that the details of individual members of that resource pool are abstracted away and presented as a single logical layer to those guest applications. Guest applications are not privy to, bound to, or dependent on the details of components that are beneath the PaaS layer, thereby creating a rigid boundary. This abstraction reduces the amount of direct control an application has over its host environment, and in exchange, is provided certain functional guarantees and systems services. Furthermore, it could be argued that this PaaS computing platform be accessible to the developers who write guest applications in a self-service or near self-service way. Up until this point, I think nearly anyone who considers themselves a student of cloud computing would agree. After this point, things seem to fall apart since:
- No one agrees on what PaaS should provide
- Those who do agree on what PaaS should provide tend cluster around certain functional capabilities, where the clustering *seems* (not certain of this yet) to not be motivated by ideology but by a market wide “easy win” mentality
- Hampering of creativity due to other cloud models such as IaaS distracting focus from making revolutionary progress on the more promising end game that is PaaS
The natural question anyone would have is “Sinclair, so what are the feature and functions that define PaaS beyond the systems definition you gave earlier?” I’ll do my best to provide some direction, and then circle back to the title of this post. As I described earlier, PaaS defines a layer that sits above a pool of OS/network resources, but below guest applications in such a way the details and control are abstracted away by the PaaS. As such, a corollary is that at a bare minimum, a PaaS *must* allow developers to deploy and manage applications in-spite of the loss of control and being abstracted away from detail. This should not be looked at as a value of PaaS, but rather a requirement to achieve some level of fidelity with the pre-PaaS workflows that were part tooling, part developer manual labor, and part luck. No PaaS vendor should be proud of this achievement - it’s the scholarly equivalent of getting a ‘D’ on a test and trying to spin the fact that you barely passed as “100% success at not failing.” Granted, it’s a bit better getting a ‘D’ in that a minimally implemented PaaS at least takes the tedium of manual, time intensive, error prone application deploy and manage processes and automates them in a way that is generally flawless. Things like deploying apps and scaling apps become trivial button push operations on PaaS offerings, pushing application bits to servers and updating load balancers, among some other minor things. Nonetheless, this is not the revolutionary model that cloud computing has promised, at least that’s not what I consider “insanely great” and certainly wasn’t the model I envisioned to be world-changing when I co-founded Apprenda.
Going back to the title of this post, all PaaS’ are NOT created equal. Most “PaaS” offerings’ feature sets amount to the basics I described earlier. You see, PaaS vendors took the low friction approach of building “platforms” that merely stand up stack instances for apps being deployed through them (notice I didn’t say to them; these PaaS offerings do not act as containers to guest applications, but rather as fancy networked installers) and deal with some network component setup. In fact, some do as little as templating VMs with frameworks and stack components so that apps can be deployed with dependencies in place. This has short term sizzle, but in the long term does not provide any meaningful world changing value. What we have is a categorical skewing that sets up a market to conceptually think of something grander when they hear PaaS, only to find something less interesting.
The problem is that most generational shifts in computing were accompanied by new runtime models where the runtime or meta-runtime acts as a host to guest applications. Think OS, or application server, or even a browser’s Javascript engine. Cloud computing is typically broken up into 3 layers: SaaS, PaaS, and IaaS. PaaS was supposed to be the layer where the generational runtime model became defined for cloud computing; the layer that provides higher order intrinsic value peculiar to the new computing paradigm of cloud and resource abstraction. Some of us PaaS vendors share this vision and have started down technical strategy trajectories that define new runtime models for PaaS-based apps, while others have not. Cloud computing changes the computing model enough that to be a “platform” but not build a new runtime is likely to provide trivial value, and as a result, little differentiation among similarly tooled competitors. The lack of differentiation comes from feature convergence that is natural when systems lack a new model that can act as a spring board for differentiated value – which is exactly what a runtime provides. Subramanian and Kepes were likely identifying with this feature convergence, hence their frustration.
So why does a runtime need to exist, anyway? First, let’s level set on one thing: one of the major goals of cloud is to abstract away details of underlying resources. Period. Cloud forces an application-centric model (Thanks goes to James Urquhart for articulating this), and as such, needs to remove distractions created by irrelevant, low-level details. Much like VM-based runtime paradigms such as the JVM and CLR got rid of the need to deal with what integers were stored in what CPU registers, cloud should get rid of the need to worry about execution time details about OS’, network routing, etc. Cloud has done two things: it has raised the ceiling for potential application architecture complexity AND opened the door to new types of previously unavailable value. Without going through a formal proof of sorts, it should be obvious that a PaaS that merely pushes bits onto servers and updates load balancers is incapable of supporting the execution needs of applications that need to deal with abstract resource concepts and new levels of architecture complexity due to the nature of network-distributed resources. It would be akin to thinking that a fancy C++ library could provide pari passu value to the JVM: it simply couldn’t. As a cloud application executes, it needs an underlying active system that is doing constant heavy lifting to make magic happen, and not just waiting on the sidelines for the next app or infrastructure management event. A great PaaS will:
- Provide self-service access to developers
- Provide application management tools and capabilities
- Use a runtime model that sits underneath an application as it executes, but above the infrastructure with the intent of abstracting away non-strategic details
- Provides frameworks and APIs to access higher order value
- Manage the infrastructure in a way that shields the application from as much impact as possible
The last piece of this book-of-a-post is helping identify what a PaaS runtime looks like. An anchoring theme for a PaaS runtime is active participation in the execution of guest application code. As such, you will typically see non-trivial PaaS offerings do some number of the following things:
- Implicit participation in application messaging at various tiers of typical application architectures. Additionally, the PaaS my provide declarative or imperative control to guest applications over application messaging.
- Use “resident code” to instrument behavior into executing application code. Much like traditional runtimes forcibly load libraries into your memory space, PaaS runtimes may load code and data that co-habit your application memory space
- May use code generation to augment guest applications in a way that is orthogonal to the guest applications functions, but in alignment with the PaaS runtimes execution needs. This might be tough to understand if an example is not provided, and the only example I know of is what our Apprenda PaaS does. To simplify the example, let’s consider web services deployed to the Apprenda PaaS. REST and SOAP web services go through a compile phase when they hit our hosting containers. This compile phases adds control end points for direct P2P style communications with any instance of that SOAP or REST service, allowing the “node” to participate in direct control calls from the runtime fabric. The end result is that each node is an independent peer entity on the distributed system that is Apprenda, but is also “stitched in” to fabric behavior.
- Activate behavior autonomously based on what guest applications are doing. For example, on an application crash, detecting the actual error (where possible) and acting on it would be an example of this sort of autonomic management.
- Provide APIs and frameworks to the guest applications that trivialize access to complex architecture value. Think publish/subscribe, map/reduce, and message brokering models.
- Might influence or modify how requests and even threads behave in the application as the application executes.
- Provide general purpose APIs for runtime services from the platform.
This list is definitely not exhaustive, but you get the picture. This the stuff that makes cloud runtimes real and interesting, and this is what differentiates some PaaS’ as being “insanely great” versus others that, while not bad, don’t provide this level of value. This is the stuff that the future is made of, and hopefully the market evolves quickly enough where Subramanian and Kepes can both agree that innovation and value abound.
read more
