Blaming DevOps (or full-stack, for that matter) for a toxic company culture is just too easy.
What I've learned is that:
1. DevOps is simple to explain
2. For some reason, everyone has their own idea on what it means, and most of them are wrong
Key points from my perspective:
1. DevOps is an evolution of Agile and so all agile practices are a subset of DevOps. This point obviates the need for any points past number 2 below.
2. It's a process which is supposed to get operational knowledge involved in the development process much earlier to build it right the first time
Its over aim is to combat the fact that you can be proficient in only so many things. As you become more specialized in one area, your time becoming proficient in other areas suffers. So a pure dev is unlikely to know much about QA or Hosting, but that domain knowledge would be valuable for them to have in their daily duties. So you try and implement a process by which they have regular access to where that domain knowledge lives, and can make use of it.
It's really just a way of trying to solve the "Jack of all trades, master of none" problem. Put another way, it shouldn't be shuffling more duties onto the dev to save money on headcounts, but a way of increasing the value (not volume) of a Dev's already high-value work.
https://tim.blog/2007/09/14/the-top-5-reasons-to-be-a-jack-o...
The Paint Drip concept has been around for a while now, so I'm surprised people still reference "Jack of all trades, master of None" especially in the software dev industry.
So in larger organizations, people can and should specialise more, and not everyone should be "jack of all trades".
But there is an important lesson in DevOps: owning your software from creation through testing, deployment and observing how it runs in production cases, and being partly responsible for handling Operational issues in it has great benefit. It closes a feedback loop that will greatly benefit your software. It doesn't matter if your organisation is large, that learning from the truth of production is still available to you.
I agree that it's important to be thinking about these future states and having those conversations from day 1. But, I also think that it's easy to abstract away all of the various pieces and dependencies of some application, because we're sold by cloud providers that this design is "reliable" and "robust" and more generally speaking "a better design." But, what if those things aren't actually needed at that point in an applications life? What problem is really being solved if these things don't present a problem? If the application has a few dozen daily users, why is every single piece of it an AWS service vs. a single AWS EC2 instance? It gets even worse than this, of course. I've seen instances where a team of developers had no idea their application was using ElastiCache and experienced application outages as a result of AWS maintenance windows.
Sometimes, I guess, it just strikes me as putting the cart before the horse. And specifically with AWS (but somehow less so with Heroku or DigitalOcean, in my head).