It depends upon what you use your ops staff for that can mean different things and how you're structured across a service lifecycle. For example, WhatsApp had n

It depends upon what you use your ops staff for that can mean different things and how you're structured across a service lifecycle. For example, WhatsApp had no operations engineers that were dedicated - everyone was an operations engineer that was writing the software by helping keep it alive. This to me is the intent for the devops organizational style - your developers have full visibility and responsibility into seeing their code through the entire cycle of existence and can quickly fix and prevent problems better than split teams. While most software developers tend to be terrible operations engineers and vice versa, I'm quite sure that well-written software makes operations work far, far easier and thus makes O&S much cheaper as a result. Also, a lot of companies opt to use Heroku first then migrate to basic ol' AWS once that gets far too expensive for them and may hire an operations engineer or two to replace the cost and to help them scale better with capital. NoOps in a very literal sense being used to describe tech operations is something I never think I'll see anyone take seriously and that can scale.