This isn't unique to devops, this is a general software thing. But there is an answer, which is the standard technology stack:

- AWS - Postgres - Linux - Docker - Jenkins or similar - Slack - Pagerduty - Jira - Packer - Terraform - etc

If you stay on the path there will be dozens of tools, plugins, and paths to do outstanding things with minimal work. Parallelising builds for example is built in to jenkins (if you define the workflow), which will autoscale workers in a setup that takes < 1 hr to setup in aws.

If you're writing code to solve a problem that a standard tool exists for, you're the problem.

Kind of rude but parallelising builds was referring to the work that Uber did with their monorepo setup due to all their microservices.

< 1 hr to setup Jenkins, nevermind with auto-scaling workers on AWS, is an obscene underestimate.

You'll probably spend at least an hour figuring out IAM permissions before you even get to deploy a VM.

nah just throw few layers of abstraction and throw a templated YAML at another tool that sets it all up for you!

Something broke ? Well, rip it up and reinstall! But what about the data ? Who cares?

Well, you will certainly the first time sure. But in your next 3 jobs it should be much easier.

For me what upsets me about devops work, is that for many organizations it is a synonym for systems engineer, lots of Ops and very little Dev.

This. I didn't see any meaningful difference between 'devops' roles and 'sysadmin' roles. Devops is a more recent name which had a IaC movement behind it, but it looks like the name stayed, but the role regressed.

Being a company and having a job title with DevOps in the name is a great way to out yourself as not following the DevOps philosophy. It’s quite ironic. If you know you know.

The term Devops has been almost completely co-opted by sysadmins at this point.

Platform engineering is a term I used to use in its place to try and differentiate but it seems that's being taken over now as well.

"diagrammatic observability and live visualizations of systems"

I hear you. IMHO there's massive opportunity / unmet need here. And working on the things that interest and excite you is the surest path to (or maybe even the definition of) success. I hope you can find a way to start pursuing your ideas! Good luck!

Surely Github workflows https://github.com/actions/starter-workflows or Gitlab templates is the culmination of your devops work?

Not Kubernetes (?) unless I missed something.

The rewarding thing for me is applying this and other sensible defaults like observing iteration speed and driving delivery..

In our previous iteration of our startup. We were trying to build day2 infrastructure automation platform. Based on interview with customers, engineerings, managers and first version of the product, we arrived at the conclusion that it is close to impossible productize because of the exact the reason the commentor is mentioning. Starter workflow or templates sounds like a good idea but in reality minor tweaks need to make it work will push you to make significant investment to learning them.

In real world, permutation and combination are endless. Every org has peculiar problem either created by the engineers themselves or are result of certain business decisions.

I'm imagining something similar to a 3D wireframe model of networks and systems, with particles that move around between nodes that represent requests or IOPS.

Circuit breakers, bottlenecks, IOPs, load shedding, traffic behaviours can all be visualised.

I'm not sure how you would represent latency with this visualization but that's also important. It more represents throughput.

Can also be used to represent human work/tasks itself.

Sounds a bit complex, I usually stick to the R.E.D. method for services and from the devops perspective largely iteration speed.

Well you could use some heatmap to represent latency, where the hottest part would be those of high latency, turn those particles and boxes red or blue depending on their mean latency...

What upsets me about DevOps, is I know ops pretty well, but am not on par with dev, and every job that just needs someone to ops work now wants to quiz me about O(n) before they'll interview. Then I look around at the people who are good at the Dev part and the don't know their way around an os or cloud infra.

Same, and seeing companies puting devs in charge of interviewing ops people makes the game even worse.

Those concepts arent that hard though. Just spend a day and familiarize your self with it. The most important take away from those kinds of questions are, can you pick the right data structure when you need to. Using a list vs a hash map, and will you avoid doing things like nested for loops. Big O just puts into words why you want to avoid those things. Most of the concepts should be intuitive already if you have some experience. Personally I haven't seen an interview go in deeper then that.

If your writing a script that will touch 10k servers, the operation is likely already slow. if you throw an unnecessary for loop that iterates over everything and runs something, that's going to a painfully slow script and wasteful.

Big O is kind of a valid question for ops in terms of response time versus load.

> and there's no cross polenation except when they are open sourced

This is true of software dev as well. Open sourcing things is something you have to sell well and demand up front.