> If the “DevOps” team ships a Postgres RDS instance it will run fine forever, that is until an application starts using it. All of a sudden a cascade of N+1s h

> If the “DevOps” team ships a Postgres RDS instance it will run fine forever, that is until an application starts using it. All of a sudden a cascade of N+1s hit, the CPU spikes, and queries grind to a halt. Who is woken up? And why does this always happen at 2 AM? In this scenario, there is nothing for operations personnel to do, yet here they are. This is definitely a symptom of a broken model and not what I would call devops. IMO the most important tenant of devops is "if you build it, you run it," meaning the appdev team that decided to use Postgres RDS is the one getting woken up at 2am. It's also, in my experience, one of the best ways to reduce masturbatory engineering decisions and get people to focus on picking boring technology that works. Coding up a serverless application in Rust that's using a CockroachDB backend at a Python/MySQL shop would get a lot of engineers excited, but those people would be less excited knowing they're going to be the ones paged at 2am when this new and exciting architecture falls over in an unfamiliar way (as opposed to Python/MySQL, where a wealth of operational knowledge at the org has already been built up). Similarly, it naturally reduces architecturally complexity. Younger senior engineers love drawing boxes of queues, multiple microservices, event buses, etc to show off their skill in creating the ultimate engineering fantasy, but once you throw enough late night operational incidents at a senior engineer, suddenly the preferred architecture becomes "an executable running on a box that I can SSH into when things go wrong."