PaaS Won’t Become a Feature of IaaS: It’s Unnatural

By Atos Apprenda Support

Over the past few months, I’ve read a number of articles and reports (like this one by David Linthicum, this one  by Brandon Butler, and this fine specimen by Alex Freedland of Mirantis) that predict or speculate about the demise of pure-play PaaS layer (software or otherwise). The prediction is that IaaS will subsume PaaS in an engulfing process that I can only visualize as some sort of phagocytic event. My take? It’s a batty idea and I have history and logic on my side to dismiss it so readily.

First, let’s talk about the concept of technology stacks. Generally speaking, any layer of abstraction (e.g. application server) forces any layers above that abstract layer (e.g. application) to be indifferent of what sits below it (e.g. hardware). A true “upstack” play minimizes the importance of components that are downstack. This is the fundamental reason one can write a Tomcat application and run that app on Tomcat regardless of whether the container is sitting atop of Windows or Linux. Tomcat minimizes the importance of the OS.

That isn’t to say OSs aren’t important, just that from the perspective of an application sitting in Tomcat, it is much less important to the architecture of the app than if the app was sitting on the OS directly. An upstack layer makes an effort to treat components downstack from it as leakfungible, with no specific implementation having an unnatural advantage. Why? Because otherwise it would be a terribly leaky abstraction. We all know that every abstraction is leaky to some degree, but good architectures tend toward the “not so leaky” side of the spectrum.

Now, back the specific question of “Will PaaS become a feature of IaaS?” One of the primary tenets of PaaS software is that it provides the customer infrastructure independence. I have not had a single Apprenda customer not be interested in either the story of infrastructure independence or the real end-state of infrastructure independence. If we think about this tenet and the leaky abstraction discussion, one of two things must be true if PaaS were to become a feature of IaaS:

  1. Customers will sacrifice the infrastructure independence tenet. Why? Because those features will be tied to a specific IaaS layer (and IaaS is the new hardware). This will make IaaS choices more important than PaaS choices and will severely hamper the ability to achieve a strategically low-risk hybrid outcome.
  2. Leakiness will surface because it’s too tempting for layers that are purposely intimate to not “take advantage of” features in lower layers. This is a terrible outcome because not only was the independence tenet violated, but it was done in a way that “Trojan horses” the IaaS layer into a guest apps’ architecture. Yuck.

The end result of the first of these is blunt stack lock-in. The second reality mentioned is more subtle because leakiness will cause guest application to inadvertently bind to the IaaS layer and not to the PaaS layer. Neither of these outcomes is customer-friendly. If we look to history, tailthe customer push has always been as rigid of a decoupling as possible. It’s why OS, app servers, and runtimes like the JVM work the way they do. No one that I know of would willingly choose to let the tail wag the dog in an architecture stack and be happy with the outcome.

In reality, the opposite will happen. PaaS software will dominate the discussion and provide for a future where infrastructure is minimized in the context of upstack decisions. Customers will have freedom to optimize the layers independently and not be shackled by a “downstack dictator.”


Atos Apprenda Support

View Comments
  1. Joe Bentzel, Platformula GroupMarch 12, 2014

    When software and cloud superpowers attempt to ’embrace, extend & expropriate’ an emerging category of innovation, as the alpha IaaS vendors would like to do with PaaS—It is in fact a “phagocytic event” that generates a “downstack dictator” effect as accurately described by Mr. Schuller. In my book “Asymmetric Marketing” I refer to this phenomenon as ‘category regime change’. In addition to the technical defense articulated above, there are also various strategic marketing counter-measures that can be utilized to defend an emerging category and its category innovators from being ‘feature-ized’ out of existence. These counter-measures can be particularly effective in complex enterprise IT markets focused on re-inventing themselves for the digital economy.

  2. Joe Bentzel, Platformula GroupMarch 14, 2014

    Sinclair: Would like to have the bulk of this conversation offline so as to not ‘wake up the competitor sleeping dogs’ intent on featurizing the PaaS category out of existence. Feel free to ping me at and we can continue a dialog.

    In terms of the high level point I am making about countermeasures the first thing to do (as you have been consistently doing) is provide thought leadership that clearly and unambiguously defends the intrinsic merits of the value proposition vs. commodity IaaS. And continue to stay on offense in this endeavor especially in the face of relatively clueless ‘journalists’ who carry water for certain IaaS agendas. At the end of the day you and I both know that enterprise IT leadership and enterprise developers are not going to bet the farm on commodity IaaS but will seek to create and defend and extend their own innovation DNA that capitalizes on their legacy investments and legacy data. That’s where your version of high-ROI, enterprise-ready PaaS shines.

    I have registered to attend your online GigaOM webinar next week and will do some homework over the weekend and get back to your with a more detailed set of suggestions. Zap me a quick email so I have an address. Best, Joe

  3. Jeremy CowanMarch 26, 2014

    I agree that PaaS will ultimately come to dominate, but shorter term I think you need to offer a bridge that allows developers to bring their own services. At Google’s Compute Platform event Urz Hölzle said he thinks the distinction between IaaS and PaaS is a false dichotomy and announced support for managed VMs that have the GAE codebase installed and managed by Google.

  4. Sinclair SchullerMarch 27, 2014

    That’s fair, but at the same time, what Urz described was more of an IaaS++; essentially, by bootstrapping GAE code into a VM, the VM becomes manageable by GAE’s fabric. That’s it. The app itself isn’t tapping into the PaaS capabilities so it’s more autonomous IaaS management then it is PaaS.

Comments are closed.