In February, I wrote about how Platform-as-a-Service (PaaS) has become an approach that appeals not just to developers, its original audience, but also to admins and architects. It allows IT operations, admins, to define policies and standardized environments for developers and then turn things over to developer self-service and the "machinery's" automation to do the rest. It yeps architects to standardize the developer workflows and accelerate application development in their organization.
In this post, I dig a bit deeper into why PaaS is able to appeal to all these different roles. (Giving credit where credit is due, I thank my colleague Gunnar Hellekson, who is the Chief Technology Strategist for Red Hat's US Public Sector group. This post was inspired by a back-and-forth over email we had following that earlier post.)
The fundamental reason, I contend, is that the PaaS abstraction sits at a very organizationally useful place for many types of application development. More so than Infrastructure-as-a-Service in many cases. (IaaS does offer more flexibility in certain respects. However, in the case of Red Hat's OpenShift PaaS, multi-language and multi-framework support—in addition to a plug-in cartridge architecture—gives a lot of flexibility within a PaaS model too.)
To see what I mean, consider the difference between IaaS and PaaS from the perspective of what the consumer of the service cares about and doesn't care about. (Read "doesn't care about" as "doesn't have any visibility into.")
Unlike IaaS, in the case of PaaS, the operating system and application platform, for the most part, are abstracted away from the user (Java or web developer). I say "for the most part" because aspects of the application platform, such as language version or framework, certainly matter to the developer but underlying aspects of the platform that aren't exposed in the form of APIs, programmatic interfaces, or language features don't.
Here's how Gunnar put it to me.
One of the greatest benefits of a PaaS is its ability to create a bright line between what's "operations" and what's "development". In other words, what's "yours" and what's "theirs".
Things get complicated and expensive when that line blurs: developers demand tweaks to kernel settings, particular hardware, etc. which fly in the face of any standardization or automation effort. Operations, on the other hand, creates inflexible rules for development platforms that prevent developers from doing their jobs. PaaS decouples these two, and permits each group to do what they're good at.
If you've outsourced your operations or development, this problem gets worse because any idiosyncrasies on the ops or the development side create friction when sourcing work to alternate vendors.
By using a PaaS, you make it perfectly clear who's responsible for what: above the PaaS line, developers can do whatever they like in the context of the PaaS platform, and it will automatically comply with operations standards. Below the line, operations can implement whatever they like, choose whatever vendors they like, as long as they're delivering a functional PaaS environment.
We spend a lot of time talking about why PaaS is great for developers. I think it's even better for procurements, architecture, and budget.
In other words, PaaS is a nicely-placed layer from an organizational perspective because it sits right at the historical division between operations roles (including those who procure platforms) and application development roles—thereby allowing both to operate relatively autonomously. We also talk about PaaS as enabling devops, which is to say the melding of developer and operations roles. But what we really mean when we talk about develops in this context is that operations can setup the platform and environment for developers and then the PaaS itself takes care of many ongoing ops tasks such as scaling applications.
Is this division of roles set in stone? Of course not. And, in fact, some companies that grew up with the cloud have done that to various degrees. Adrian Cockroft of Netflix has written and spoken about the topic frequently and I recommend his blog highly. (Adrian has referred to PaaS as "NoOps," partly for the reason cited above—i.e. that it's no so much that developers do ops in a PaaS but that the "cloud" does ops. All of which is also a useful reminder not to get too wrapped up in xOps labels.)
However, in the more general enterprise case, there's a lot of inertia to organizational structures and skill sets. As the saying goes, "technology is easy; people are hard." As a result, useful abstractions that map reasonably to existing roles and responsibilities are valuable. And that's what PaaS does.