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.
Long break
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!
| |
We don’t talk about PaaS
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:
- “Middleware” - we end up saying “services” (as above) which is too broad.
- “Application Life Cycle Management” (ALM) and “Software Development LifeCycle” (SDLC) - these mean “all the project management and tools developers use that does not involve actual coding.” The phrase “developer portal” is set to take over here. I hope not: “portal” is just sort of…ugh.
Original content
- There have been many Software Defined Talk episodes since last time. This episode, referenced above, where I discuss The Janitor Strategy is one of the better commentaries on done on that show in awhile. Also, the opening about the philosophy of rocks is fantastic, I don’t care what people say. #rocktalk forever! We’re switching to recording at 10:45pm my time, so it’s going to get rough.
- I hosted two talks at our .Net Beyond Conference. If you’re into application modernization, this discussion about modernizing an old Silverlight application is great, watch it!
- I’ve done several of my Tanzu Talk videos since last time. Here is how I make salsa:
|
Relevant to your interests
“Most of our cloud computing is on Google, and most of our big data work is on Google’s data platform. We also have benefited from a longstanding relationship with Dell and with VMware and, in particular, VMware spinoff Pivotal. VMware’s Tanzu Labs, which provides super effective help to organizations who are trying to become better at building software themselves (we’ve also hired a lot of alumni from that org). On the data and machine-learning side, we’re currently doing a good amount of partnership with Deloitte on the third-party data and data-science side.”
|
Consider this as a pitch letter, selling your services by specifying how the work will be done, your approach to work, and even your pay. Also, on th old “paid with exposure” trap: “Some people in my position would expect an increase in business after being associated with your band. I, however, already have more work than I can handle, and frankly, the kind of people such superficialities will attract are not people I want to work with. Please don’t consider that an issue.”
|
| |
Desk Setup |
“…emails between 50 and 125 words had the best response rates at just above 50%.”
|
“The next time you are attending a formal presentation at a conference, ask yourself these questions: Is this better than all of those Zoom calls I am turning down? Is this better than the next best YouTube clip I might be watching?”
|
Simmering b-stories that become a-stories later on.
|
“It’s no utopia, but it’s better than any real world place I’ve ever lived.”
|
Pictures,
|
| |
Executive Round Table Plan, Sep. 2021. |
“DevOps - which differs from other well-known lean approaches, like Agile, in that it focuses on improving delivery outcomes versus the process of delivery.”
|
Backstage platformasaproduct platforms cases
|
“OKRs do not replace or supersede core team member responsibilities or performance indicators. OKRs are additive and are essentially a high signal request from your leadership team to prioritize the work. They typically are used to help galvanize the entire company or a set of teams to rapidly move in the one direction together. They are expected to be completed unless you have higher priority work that is surfaced and agreed to by leadership.”
|
“Here’s a set of SaaS OKR examples for startups that help balance driving demand, sustainable growth and good ROI.”
|
A list of things to define to get to an ABM programming.
|
Engage with my brand!
Download three of my books, on improving how large organizations use software to achieve those lofty business outcome goals…for free!
|