[nabdab]

People can’t agree what devops is, sure. But I feel like it’s extremely easy to tell what devops isn’t. If you don’t have any confidence in your releases before you’ve done extensive ad-hoc manual probing you aren’t doing devops. If your using oracle and Delphi even though none of the developers would chose it because “that’s what management decided” you are not doing devops.

The rest of the story is just about the tooling and management decisions that support getting out of those pits. You use micro services because it allows developers to use whichever tools they want as long as they solve the task. You use automated tests and deployment pipelines so the team and organizational procedure to be confident in releases shifts from becoming “talk to Tom and get his blessing after he’s spend a week probing everything” to “well if it passed all tests and deployed then it’s a go.

It’s not like the technical issues suddenly disappear. You need to set up your tests to a level where you are confident in the pipeline. You still need to spend the time and resources making sure your microservice infrastructure is working.

But at the end of it you’ve removed the power of the gits who where previously controlling the techs allowed and the releases, and your letting teams move forwards through proving their work rather than constant audiences with individuals who are gatekeepers because they spend 20 years in the same organization and feel that everything invented in the last decade is scary.

[kelnos]

> If your using oracle and Delphi even though none of the developers would chose it because “that’s what management decided” you are not doing devops.

What does that have to do with DevOps? Clearly that's not an ideal situation, but that has nothing to do with CI/CD pipelines, developers handling operations work, etc.

[weberc2]

I think they're driving at "management is dictating technical decisions"; many people view DevOps as a cultural shift (if not a mindset) that includes empowering developers.

Interestingly, your question of illustrative of the "DevOps has no clear, standard definition" problem.

[weberc2]

That brings to mind another interesting point--even if you can tell what DevOps isn't, so much of a "DevOps" role at any particular company is dependent on the technologies that the company has adopted. I imagine DevOps looks wildly different at a company that deploys a monolith to an EC2 autoscaling group versus the company that deploys microservices to Kubernetes. Similarly, whether you use a monorepo or a multirepo. These sorts of concerns drive virtually everything about the DevOps role--the entire structure of the CI/CD pipeline, the strategies for fast rollbacks, the local developer tooling, how much time you spend at which layer (e.g., if you deploy to EC2, you're probably spending a good chunk of upfront time configuring log exfiltration and process management versus something like Fargate). And this says nothing about which cloud provider you're familiar with, or the cultural concerns (one company's DevOps might be chartered with driving cultural change while another's is taking strict orders from management).

Given how large the gap between any two given DevOps positions, I wonder how valuable it is to have "DevOps" job reqs or conferences or other "DevOps" things.