You’re right. And it wasn’t my intent to editorialize (to imply I feel one way or the other about the subject.) But I can read how an opinion could be inferred. Anyway, my actual opinion is that people like us tend to be more useful than not, but also it definitely takes people with more specialized knowledge to make progress with some organization goals. For example, at my current role we have a team of people with a much deeper background in mathematics (we’re in the financial sector), algorithms, and computer science in general. Due to a life event, I dropped out of my computer science degree towards the end of my second year, and ended up pulling myself through operations roles (which I typically found comparatively boring) until I landed in DevOps after a lot of open source work and networking. But I am not as strong as some of my peers in mathematics, algorithms, and computer science topics (what is a big/little endian lol?)

Anyway, cheers. In short, I agree with your take.

> Have Dev and Ops collaborate closely

That’s what DevOps is… or, was. I remember when it was new; that was the whole thing: dev and ops should work together. A break from the norm of the time that dev throws it over the wall to ops and never thinks about it again. What a tragedy that it’s been cargo-culted into its current meaning of “devs do ops” (poorly).

my experience hasnt always been this, but generally speaking, this is the way to be successful - you need developer-oriented people doing the work. in some ways its harder than coding, coding has more structure than devops automation

> Ya, and everywhere I've worked, that team is called "devops".

But then that team is only doing operations and not development. Unless they are committers to k8s.

This is one of those cycles that IT does regularly every other decade.

In the early days, computers were huge things that were maintained by a team of specialists (and who actually soldered things together). Getting anything changed involved a series of paper forms and waiting for a specialist to do it for you.

Then came the microcomputer revolution and computers became small things that sat on desks and were maintained by the office geek. Changing anything meant talking to him (it was always him) and it would be done by lunchtime, and you owed him a coffee.

Then companies learned that this meant that no two offices had the same configuration, application suite, or even operating system. IT was centralised, and every office issued with the same stuff. Getting anything changed meant filling in forms and waiting for System Administrators to get around to it.

Then Agile and the Cloud happened and while the rest of the company had to carry on filling in forms, the IT Department turned into Engineering and DevOps was born. Every developer learned how to deploy their stuff to the cloud by themselves.

Then organisations worked out that that meant that applications were deployed badly, using a wide variety of tools and technologies, and essential security practices got skipped because no-one was responsible for them. So DevOps was turned back into SysAdmin and the forms reinvented as JIRA tickets.

And so we go on. There are micro-cycles within these ones, like the one about terminals (are you typing on the actual computer, or on a terminal that talks to the actual computer which is somewhere else? The answer depends on which decade you're in).

The ideal solution is somewhere in between (enough central control for it not to get into a mess, but enough decentralisation to prevent bureaucracy and allow for agility in the actual business). But that is a very hard balance to find and keep.

But somebody has to know k8s administration.