How PaaS makes "developer-defined infrastructure" fences possible

Over at VentureBeat, Jerry Chen of Greylock Partners writes:

We are entering the age of developer-defined infrastructure (DDI). Historically, developers had limited say in many application technologies. During the 1990s, we effectively lived in a bilateral world of Microsoft .NET vs Java, and we pretty much defaulted to using Oracle as a database. In the past several years, we have seen a renaissance in developer technologies and application infrastructure from a proliferation of languages and frameworks (Go, Scala, Python, Swift) as well as data infrastructure (Hadoop, Mongo, Kafka, etc.). With the power of open source, developers can now choose the language, runtime, and database that make sense. However, developers are not only making application infrastructure decisions. They are also making underlying cloud infrastructure decisions. They are determining not only where will their applications run (private or public clouds) but how storage, networking, compute, and security should be managed. This is the age of DDI, and the IT landscape will never look the same again. 

In part, this reflects developers as The New Kingmakers as my former colleague RedMonk’s Stephen O’Grady has eloquently written about. Like any meme, the ascendency of developers as IT decision makers can be overstated. Developer

s flock to Apple’s app store for the same reason that Willie Sutton robbed banks. It’s where the money is. Not because it’s a wonderful developer-focused experience. Nor are we living in a NoOps world, a term that caused a bit of a furore a couple years back.

That said, many of the most interesting happenings in enterprise software today have a distinct developer angle whether or not they’re exclusively built around developer concerns. Containers and their associated packaging, orchestration systems, and containerized operating systems (like Red Hat Enterprise Linux Atomic Host/Project Atomic) certainly. An expanding landscape of programming languages. (To quote Stephen O’Grady again: "an environment thoroughly driven by developers; rather tha

n seeing a heavy concentration around one or two languages as has been an aspiration in the past, we’re seeing a heavy distribution amongst a larger number of top tier languages followed by a long tail of more specialized usage.”) And even much of the action in data is at least as much about the applications and the analytics as about the infrastructure.

However, to Jerry Chen’s basic point, it’s also about separating the concerns of admins and developers so that each can work more effectively. As I’ve written about previously, this is one of the reasons why a Platform-as-a-Service (PaaS) such as OpenShift by Red Hat, is such a useful abstraction. It's 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. And in so doing, it helps to enable DevOps by providing the means for operation

s to setup the platform and environment for developers while the PaaS provides self-service for the developers and takes care of many ongoing ops tasks such as scaling applications.[1]

[1] A PaaS like OpenShift also enables DevOps in other ways such as providing tools for continuous integration and a rich set of languages and frameworks but I wanted to focus here on the abstraction.