Thread by @mipsytipsy

a caviar-quality rant on deployment, security, testing ... actually more like five rants stuffed into a single trenchcoat. via @beajammingh

mumble.org.uk/blog/2022/02/0…

@beajammingh the title particularly caught my eye. for the past month or two i've been sitting on a rant about how i no longer associate the term "devops"** with modern problems, but with fighting the last war.

** infinitely malleable as it may be

yes, if you have massive software engineering teams and operations teams and they are all siloed off from each other, then you should be breaking down (i can't even say it, the phrase is so annoying) ... stuff.

but this is a temporary stage, right? a bridge to a better world.

...a world where you just don't build those stupid siloed towers in the first place.

a world where every engineer is writing and shipping code to production, and owning/operating the code they ship.

the reasonable distinctions to be made aren't between people who are writing code vs operating code, but between groups who are writing & operating different *kinds* of code.

sometimes that will be infra or platform teams, most commonly teams oriented around products.

if there's anything we can learn from the past 30 years of software trench warfare, it's that Bad Things Happen if you separate the roles of designing, writing, and maintaining software into three different groups.

and by that, i mean Bad Software Happens.

i don't say this to denigrate the immense amount of expertise that goes into operating large software systems, or running infrastructure at scale. my ops blood runs deep. i *know* how hard it is.

that is why it's so incredibly hard to find, hire, train, recruit and retain those people. which is just one of the many factors driving companies to outsource those skills to companies who can do it better than they can.

i've written about this at some length before. a few key points:

1) there are two types of software; the code you write and own yourselves, which defines your business, and all the code written by other people that you have to run in support of it.

thenewstack.io/the-future-of-…

2) "product code" is your crown jewel, it's what makes your company valuable. this is the code you should be writing, maintaining, and shipping as often as possible. you should know it intimately. you should instrument it intimately. you should practice observability and ODD.

3) "infrastructure" is everything you *have* to do, in order to get to the stuff you *want* to do. that doesn't mean it's not important -- doing infra well can be a huge competitive advantage. but it is inherently a thing to be minimized, and a candidate for outsourcing.

4) why? because engineering cycles are limited, and the more of them you can devote towards solving first-order business problems the better.

writing a calendaring library might technically move the business forward, but unless you're a calendaring company, you prolly shouldn't.

5) breaking up the software lifecycle into roles like dev, test, and ops inevitably produces such low quality software that devs refuse to be on call for it, so you have to hire armies of ops people as cannon fodder.

these teams, and there are many, need the devops gospel badly.

6) "devops engineer" seems to have become the term of art for "ops person who can automate things and write some code, but doesn't touch the crown jewels".

these jobs aren't going anywhere.. after all it turns out running software is hard, much harder than people realize. 🙃

7) but it's ultimately a kludge role, a term that muddies rather than clarifies any purpose.

ops folks are terrifically handy; if there's one thing we're good at, it's fixing literally anything. but if i was a devops engineer today, i'd be looking to the future & asking myself:

"what do i want to be building, five years from now?"

the era of reactive, bag-holding, firefighting ops work as a profession is coming to an end (and good riddance). in the future, everyone is a builder, an *engineer*, who then operates what they build.

instead of being a catchall role, devops engineers will be:

* build engineers
* internal tooling engineers
* infrastructure engineers who write and ship code at infrastructure companies
* SRE specialists who help software engineering teams with reliability and incidents

i guess what i'm saying is that in a post-devops world, operations skills won't be seen as a cost center, but as a core competency of every skilled engineer. and the specialty skill of a few.

that's all <3