I would say that the problem in this situation is hard to avoid. If you can have an operations team who are experts on the application as well, and have the team more closely integrated with the development team, then you generally don’t need to wake up developers at night. I spent a few years on a team set up like this and it worked very well. If your project isn’t big enough for its own operation team you can share a team between a few different projects.
But I don’t think it’s necessarily that much harder to hire developers than it is to hire devops. Some managers have told me that hiring for devops is harder.
And developers should feel some of the pain—I’m not saying page them in the middle of the night, but they should be doing daytime on-call rotations. This helps align incentives and makes developers aware of reliability issues in the systems that they create.
> In my opinion your company/solution needs to be somewhat limited for "DevOps" to make sense. For everyone else, it's two separate roles.
When I think DevOps, I already think of it as a role separate from development. You have devs, and then you have devops. You can combine both roles into one, and that makes sense for smaller / earlier stage projects, but otherwise I think of devops as a separate role.
Kind of a mess because devops varies so much between companies and isn’t even consistently named.
But my experience is that it’s not necessary to wake up two groups of people—it’s either a developer that gets woken up because the project is too small or too early to be supported by operations, or it’s someone in devops/SRE/production engineer who gets woken up. There’s a lot of practices that need to be put into place to make this work, but it’s doable.