Most companies that have sufficient talent and organization/operational setup don't see a need for DevOps.
There seem to be a lot of other companies that are sucked in by its promises and think that it will solve their issues. Surprise... this didn't fix your shitty policies, disorganized/unempowered org structure, or cheap talent (cause you're unwilling to pay or train).
I assume there are a few places that can benefit from this. Maybe some medium to large tech companies with great procedures, documentation, and an empowered org structure. Especially if they're paying enough for people who can manage it. The other is probably for very small places wirh fairly simple tech where you can't afford entire teams of people so you empower someone to really own the system top to bottom (without ever calling it DevOps).
IME, letting developers have free reign over service architecture/deployment/CI/observability is a bad idea. Especially when every team comes up with their own option.
You need some sort of Devops (best practices if not a team) to provide guidance and help implement standards for these.
I agree, if we're talking about places big enough to have multiple teams. The thing I was pointing out is that most places that have multiple teams are terrible at setting up best practices. They'd be better off with a centralized "environments" team provisioning the server, network, etc so the dev teams can work on the actually implementation. At least it's easier to maintain standards, or at least consistency, across apps if the low/mid level config is handled by one team.
When I was talking about small places, I mean like tiny mom and pop non-tech companies with an IT department of 1-5 people.
Every company that has a software product also has DevOps, whether or not they call it that. If someone manages your cloud infrastructure, they're doing devops. If someone is coming up with CI/CD setups, they're doing devops. If someone came up with SOP for distributing new releases, they're doing devops.
Whether or not anyone's title has "DevOps" in it, devops tasks are still devops tasks. By the same logic, even though I watered the office plants this morning, I am still a firmware engineer- not PlantOps.
The real trap of DevOps is the assumption that it's anything new or non-essential. DevOps has existed since the notion of "software as a product" came into existence, we just didn't have a name for it yet.
None of this is to say you need a dedicated DevOps person (or PlantOps, for that matter). DevOps is an integral part of any software product, even if no specific member of the development team is dedicated solely to DevOps tasks.
I don't think those are DevOps by themselves. You have to be doing the Dev part of the system in addition to the Ops part. The traditional format is that some team or tram member would do ops work while others did the dev work.
Most companies that have sufficient talent and organization/operational setup don't see a need for DevOps.
There seem to be a lot of other companies that are sucked in by its promises and think that it will solve their issues. Surprise... this didn't fix your shitty policies, disorganized/unempowered org structure, or cheap talent (cause you're unwilling to pay or train).
I assume there are a few places that can benefit from this. Maybe some medium to large tech companies with great procedures, documentation, and an empowered org structure. Especially if they're paying enough for people who can manage it. The other is probably for very small places wirh fairly simple tech where you can't afford entire teams of people so you empower someone to really own the system top to bottom (without ever calling it DevOps).