[0xbadcafebee]

Here is how some companies "do DevOps":

  1. An operations team with a different name.
  2. A platform team with a different name.
  3. A development team with a different name.
  4. A "CI/CD team".
  5. A role (ex. "dev who automates ops", "ops who codes", "support specialist who codes", all three in one).
  6. A chart that the delivery manager maintains.

Here is what DevOps should actually be:

  1. Delivering rapidly and consistently with extremely high levels of confidence.
  2. The right people address problems correctly, immediately, the first time, and fix it so it doesn't happen again.
  3. That's it.

[wokwokwok]

Come on, this is such a joke.

Increased velocity is what business get promised, yes. It’s what you want.

The reality is that you can’t just magically make that happen.

Draw a line. Now draw the rest of the owl! Easy~

The problem has never been understanding what the desired state is… it’s always been that getting from the current state to the desired state is very very hard, and continually road blocked by:

- people who don’t want to learn new skills

- people who don’t want to seed control they currently have (over process and product)

- a lack of clarity on who is responsible for what systems

Devops is a load of hype.

There’s never been any reliable process to move to rapid delivery from it.

Yes, some teams have managed to get something that works, and there are a lot of tools and a lot of training which has resulted in over all better SRE processes.

…but by and large, that’s because of using better tools (eg. infrastructure as code) not because of devops.

When was the last time you had a “devops” guy you got to do something for you?

Right. That’s ops.

When was the last time something broke and the people responsible for making sure it never happened again were the “platform team” or an SRE?

Ops again.

You had all that before you started your devops journey.

It’s all just ops, with slightly better tooling, less outages, higher reliability and absolutely zero increase in product velocity.

Devops was the promise that by bridging operations and development you could get high reliability and faster iteration by having teams that could “cut through” the red tape and get things done.

That appears, largely, not to work.

Yes, developers that understand systems tend to build more reliable software.

No, it is not faster to do it that way, and the transition will be painful, and, because businesses mostly care about iteration speed more than reliability, even a technical success, it often a fails to deliver on its business value.

[0xbadcafebee]

It has worked well for organizations that embraced it. It hasn't worked well for organizations that paid it lip service. That's the way of the world. There is a path laid out by DevOps methods and dozens of ways to get there, but the path doesn't walk itself.

[hedora]

Note that this admits strategies where nothing of consequence is ever delivered (but each deploy has some quantifiable and measured churn), and the people that break stuff get credit for fixing the stuff they broke.

I've watched this particular breed of organizational cancer destroy many companies and products.

The end game is that people creating useless, but highly visible churn get promoted, as do the ones that repeatedly break stuff. Even if that doesn't happen, the engineers that want to build stuff inevitability flee.

[0xbadcafebee]

That's where value chain management comes in. If you can't show business value being delivered, there's no point to any of it.

It's also worth acknowledging when you don't need DevOps. Banks, for example, shouldn't need it. Their entire purpose is to be slow and reliable. Most of their money is literally just old people keeping lots of money in one place and not touching it. They shouldn't need to churn on features and ship constantly.