“I read the news today oh boy
About a lucky man who made the grade
And though the news was rather sad
Well I just had to laugh
I saw the photograph” – The Beatles

Over the past couple of days Platform-as-a-Service (PaaS) has taken some hard knocks in the press. See here and here. PaaS has always had a hard life. It’s typical middle child syndrome. It’s older sibling SaaS is very mature and is growing considerably everyday thanks to the adoption by line-of-business leaders. It’s younger sibling, IaaS, gets all the attention from the uber geeks who prefer to manage everything themselves. Poor PaaS is left trying to wring out an identity for itself; some unique value that users can grasp onto. Unfortunately, the support PaaS needs to come into its own is hard to come by these days.

I am still a big supporter of PaaS and I also know many that are still. What we all have in common is a shared understanding of both application development and operations management. This duality allows us PaaS fans to readily see that value proposition from both sides of the fence. That it can provide a common platform that spans the design-to-operate process fostering built in scalability, security and simplified application lifecycle management. It’s a common architecture for development, testing, staging and deployment of applications that removes the need to engineer a working platform from discrete components e.g. LAMP or J2EE.

However, it seems that PaaS’ days are numbered if PaaS vendors cannot capture the imagination of enterprise IT organizations. Cloudbees is a perfect example of what the future for PaaS looks like as vendors pull away from offering a platform and instead focus on DevOps and the tooling that fosters continuous delivery. Without strong revenue the number of PaaS vendors will shrink leaving a minimal number of options. As is the market seems fragmented into a couple of standards-based initiatives—OpenShift and Cloud Foundry—and a few remaining proprietary products, such as Apprenda and Heroku.

Of note, I think the container movement has a major impact on PaaS adoption because it provides a balance between enabling component engineering required to get interoperability across the application stack and the ability to package that configuration once satisfied. Moreover, it allows different versions of the components within that stack to co-exist on the same server without causing conflict. So, when WordPress JetPack plugin upgraded to version 5 of PHP I was out of luck since I didn’t want to upgrade my version of PHP on the server out of concern for breaking other applications and I didn’t want to spend hours trying to get multiple version of PHP to co-exist on the same server. I’ve since put WordPress in a container that includes MySQL and PHP eliminating that problem in the future and facilitating isolation of my applications on the same server.

Unfortunately, what many don’t understand, is that the isolation model afforded by containers is not distinct from the PaaS itself. Indeed, there are PaaS implementations today that leverage containers, such as Docker, to deploy the application. In this way, the PaaS actually does much of the work that the system administrators are doing manually in an automated fashion. Yet another reason why operations personnel should actually become more knowledgeable about the value of PaaS for streamlining and simplifying operations of applications.

Ultimately, what is important for PaaS adoption and survival is an understanding and acceptance of the role that PaaS plays in fostering agility in IT. Of course, PaaS would probably gain traction more quickly if vendors starting offering their applications for particular platforms. For example, many Java applications today can deployed on any compliant Java application server that understands WAR files. Hence, businesses purchase application servers from the likes of RedHat, Oracle and IBM to operate these applications. If the next generation of these applications were deployable to OpenShift or Cloud Foundry based environments, its likely customers would being to investigate costs and offerings to accommodate.