In the 1st edit, the author hits on something really crucial - the business has needs beyond just "the software works". He lists some frontend considerations;

In the 1st edit, the author hits on something really crucial - the business has needs beyond just "the software works". He lists some frontend considerations; a backend developer might have a list like: comprehensive observability, automated builds and deployments, infrastructure defined as code, developer function-as-a-service platforms, batch processing infrastructure, horizontal scalability, database recovery time/point objectives, compliance, and SLAs. The truth is that these ARE requirements once a project gets to a certain scale, yet they have little to do with your core application domain. To a certain extent, it is inherently complicated. But if you look at the "modern" cloud approach to these problems, it's full of additional complexity from the solutions themselves: k8s, ec2 spot market, vpcs, prometheus/grafana/jaeger, ELK, multiple environments, airflow, a database+replica+connectionpool for every microservice, terraform, jenkins, istio, lambda ... oy. It literally takes a team of people to manage the scaffolding to support the actual apps. Is that really the best we can do? I think there's room to radically simplify this scaffolding, while still meeting all of the advanced business requirements. In that sense, today's approach is over-complicated.