Developers don't want to use your words
Developers don’t want to use your words
People in the Cloud Foundry world are frustrated that the kids are just discovering the helpful, self-service, robust nature of what a PaaS does. Pretty much for a whole generation, developers have rejected the idea of “PaaS”: they preferred to tinker on their own, even from bare metal but definitely down to the VM and container level. Even Google couldn’t get market adoption of PaaS early on.
Developers like to build their own infrastructure. They always have, and they always will. They don’t want anyone, let alone sys admins or enterprise architects telling them what to do.
Now, I’m using the term “developers” loosely. Most developers are there to do a pleasurable, well paid job. They’re not there to argue in favor of infrastructure. As with all satisfied and quiet majorities, they don’t evolve the status quo, they maintain it as a side effect of sanguinity.
It’s the noisy, loud developers who cause all the trouble. They’ll argue that they can build their own cloud and runtime stacks instead of using some off the shelf - horror of all horrors - commercial runtime environment. They don’t want to - need to - use some corporate sanctioned stack.
And why not: when’s the last time centralized infrastructure was fun to use? Who likes filling out a ticket to get a developer environment and waiting days, usually weeks to get it. “I could do that in ten minutes if they just gave me root on that box!” a developer will say.
Developers (the loud ones who slow things down by second guessing decisions) don’t want to use all your helpfulness from operations. You have to help them help you....help them.
These PaaS things work really well, and one enterprises get developers using it, the developers love it and the business improves. But you have to trick developers into their own joy.
In the most genuine way, you do this by involving them in the decision and the selection of a platform. This is the notion of doing a platform as a product. The operations team that ends up being responsible for running, say, Cloud Foundry, kubernetes, SDDC, or whatever includes developers from the start in PoC’s.
It’s probably also a good idea to not call it “PaaS.” Time and time again, I see enterprises coming up with their own branding for what us vendor-types would call PaaS. They do this to avoid preconceived notions of PaaS and to gain some ownership of the PaaS-not-PaaS.
This is true for development stuff as well: one fun trick is avoid using the word “agile” when you’re doing agile. There’s too many meanings of “agile” and well known arguments for and against it, and, worse, an endless narcissism of small differences between the different agile factions. You’ll end up arguing all that instead of just, like, improving by actually following agile practices instead of whatever jalopy of practices you’re currently using.
If you’re trying to help developers, you need to launder the words you use, the concepts. Once a developer knows you’re doing PaaS, they’ll rebel and question it. “I could build this in a weekend!”
Developers love telling other people how to do their job. They see everything as a chance to refactor, rewrite, and “well actually.” It’s exhausting. And I know because I used to be that developer.
To win these developers over then, you have to involve them in the decision to start using a PaaS, getting them to think of it as their idea. You’re sort of bringing them into the operations wheelhouse. We could call it, I’m just typing out-loud here on a train between Gouda and Amsterdam: OpsDev!
Just don’t call it PaaS.
Containers or PaaS
Speaking of, this chart is a fun thought experiment for the above:
https://www.instagram.com/p/B2TW9duC_-j/
The fashionable infrastructure layer drives people’s perception of what they’re using. When Docker was the dominant thought-paradigm, developers were doing containers. They, of course, needed all the things a PaaS provided: orchestration, consistent configuration management, a services management layer, security, blah blah. But, no, it was just “containers” they were doing.
Then, as the kubernetes thought lords and ladies proclaim it’s all a platform for building platforms (I’m still a little unclear on this - like, it’s sort of platforms all the way down right? Above the developers, there’s some database people who are like, “whao! you JavaScript developers, don’t actually use PS/SQL directly, why would you do that? The database is platform for building your maze of JavaScript. And below, you know, the IaaS people are like, “hey man, you shouldn’t use VMs directly, they’re just a platform for running platforms,” and so on down the stack to the worms who make the dirt who are like [I assume they’d speak in English] “we make the dirt, man, don’t let developers make dirt, cause, like, it’s all zeros and ones down here and stuff.”
It’s as if, we’re tipped all those silos over like DevOps told us to and now we have these layers of platforms that don’t want people messing with their shit - “Ayyyyy! I’m observablitying here!”) and developers shouldn’t touch containers and kubernetes directly cause, like, there’s a bunch of sharp edges or whatever, people again describe their use of containers as a “PaaS,” or at least a platform. They’ve been told that what they’re using is a platform - ahem - which platform, rather, is built on (with? using?) the platform built on the platform for building platforms, the one that…oh boy…PLATFORMS!
A five star book
I finished Trick Mirror today, listening to it. I don’t give five stars to much of anything (except in Uber where that’s the only human option). That book is fantastic, I give it all the stars. I plan on going through it again and gave a lengthy recommendation to one of my old friends today. He actually wrote it down!
Relevant to your interests
At scale, you have to worry about the small stuff, like wasting too much pepper.. The other side of innovating is discovering all the things that don’t work.. Selling on the promise of growth instead of savings.