We Don't Talk about PaaS - Coté's Commonplace Book - Issue #59

You risk being thought a fool if you say “PaaS,” so let’s get a new phrase, and, please, don’t use “portal.” Scroll to the end for a steaming hot pancake.

Yeah, I don’t know. The stream of content comes and goes. Here’s some since last time. In case you’ve forgotten, this is my newsletter where I write barely thought-out and edited, uh, opinion pieces and analysis like the below. Also, there are links I’ve liked, things of mine that I want to shamelessly self-promote, and whatever else.

Like and subscribe!

I’ve been working on several articles, a white paper, and a book recently. These things take a lot longer to get published than I’d like, but some day!

You can start to sound too much like an out of touch old person if you start saying things like “oh, we already did that back in my day.” Once people flip your bozo bit, then most anything you say get dismissed. “PaaS” is in this category now: you can’t go around saying that the focus on and conversation about “developer experience” is, like, PaaS. If you’re working on building an integrated stack of frameworks, middleware, tools, and even developer tooling on-top of cloud/kubernetes, you can’t call this PaaS. That’s just how things are right now.

What’s annoying is that we don’t have new terms for these things, so they’re hard to express and talk about. Analysts are sort of coming up with the categories, some have great diagrams. But, because the chattering class (thought leaders) that determine words early on in technology cycles usually can’t get analyst reports, analysts have very little input into the discussion.

Basically, the words and concepts are now defined by Tweets. That’s probably…good?

Why is “PaaS” a forbidden word? I think there are three reasons, more or less in priority:

(1) “Lock-in” and control. A key aspect of a PaaS is that developers don’t need to spend much time on setting up, acquiring, and managing infrastructure. There is much automation and self-service. Every application developer wants to remove this kind of toil and focus on programming their applications. But, my colleague Rick Clark theorizes that there’s a vocal minority of developers that want to build and control that stack on their own. They are the only ones who make noise about the need to control this stack because they have special needs that the PaaS restricts them from and don’t want to get locked into some stack out of their control. I think that minority is mostly wrong, but they’re the only ones doing the talking, so they control the conversation. Once each development team (or cluster of them) believes that they have special needs that an off-the-shelf PaaS doesn’t do (or can’t be modified to do), you get each team building their own stack. This means you get a lot of different stacks in a large organization, which is a mess and counter productive. It’s great for vendors who deploy The Janitor Strategy! I don’t know - valuable lock-in discussions are dependent on the context you’re discussing them, what developers actually need, and a deep understanding of “compared to what?”

(2) Kubernetes. Sure, it’s great that kubernetes (seems to) have become the de facto infrastructure design and runtime lifecycle definition. That is, it’s a standard way to package, configure, and run applications. This is a huge deal that we’ve sort of forgotten already - in that respect, kubernetes has finally become boring! Historically, kubernetes came at a time when the idea PaaS was just figuring out the product/market fit for enterprises. Kubernetes became huge distraction from that: the vocal minority got very interested and that shifted “everyone”‘s interest to standardizing infrastructure instead of standardizing the appdev layer. Again: kubernetes is good! Just bad timing for PaaS developing as an idea and product in the market. This shift in interest spooked all the PaaS vendors who now had to focus on customer requests to do kubernetes stuff, most too late to ride the kubernetes wave of interest. Which lead to:

(3) PaaS vendors didn’t “win.” There have been several rounds of PaaS vendors, including Pivotal where I worked (now part of VMware, where I still work) and several other vendors built on Cloud Foundry. There were and are many successful users of Cloud Foundry PaaSes. But for all sorts of reasons, these PaaSes never achieved wide enough use to “win.” Tyler Jewewll’s annual developer landscape puts the PaaS marketize at $5.26bn, which seems large, but is actually not when compared to the estimate of $49bn for developer all stuff in the landscape. And, you know, AWS made $62.2bn last year. Since I work here, it’s best that I don’t speculate too much. (But, you can see some in the Tweets Matt Asay includes in a recent column, as well as other people’s.) Brian Gracey always has good commentary, listen to his explanation. Despite this notion, there are many large organizations that are running Cloud Foundry with happy developers. Brian also did some good analysis of the PaaS space back in 2015. The burger he came up with is still basically the same for the “we don’t talk about PaaS” stack, except there is only kubernetes at the bottom and it’s not labeled PaaS:

The three of these add up to PaaS having a bad reputation as a word, which I think is why we don’t talk about PaaS.

There are two phrases that are getting a lot of use:

(1) Developer portal - this is, mostly, a synonym-phrase for Backstage. Here is a Gartner report you can read for free that defines the phrase well. I think it’s good. I don’t know why you’d choose to use the word “portal” in 2022. Below is Gartner’s diagram for a developer portal from that report. You can see that it has most everything except the actual runtime. Developer portals are being conceived of as a, I don’t know, sort of overlay for kubernetes - the tools you use to build and do all the SDLC (see below) activity for apps you end up running on kubernetes.

(2) Internal Development Platform (IDP?) - pretty much a PaaS. In fact, there’s a Tweet on the front page of a definitional that says so. That site, by the way, is a great try at doing some gorilla thought-leadership, almost at the Heroku’s 12factor.net level. We’ll see!

So, you know, whatever, let’s get some new words!

As I said, you end up sounding like those old people who are all like “we’ve always been doing agile/DevOps/SRE/DevSecOps, we just never called it that.”

Bonus:

Other old phrases that are forbidden to use and also lack new words:

Download three of my books, on improving how large organizations use software to achieve those lofty business outcome goals…for free!