I think the attempts to make local workflows mirror production 1:1 (local k8s, for example) are misguided. They miss too hard on the productivity story. Especially once you start having to swap out local debugging for remote debugging (which only a handful of languages support effectively).
This is the biggest miss for many companies striving for microservice architecture. The local development story is terrible, and it stays terrible, without a lot of opinionated decisions around what your dev workflow needs to look like past the ~3-5 services mark. At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task.
That sounds like no thought was put in the system before development. Well thought out scopes & contracts between services should not create a situation like that. Reminds me of a commenter on HN who were rolling back changes to all microservices if one service needed a rollback. These kinds of issues are dead giveaways that devs are paying lip-service to "microservices." Also, devs need to understand that they don't need to be on microservices or on the latest fad. Use what works for the team. A 10-team of devs cannot necessarily adopt workflows of a FAANG.
1. Terraform repo for AWS deploy
2. Step functions application logic (server-side polling daemon)
3. Email service template
4. Feature flag configuration
5. (Something in the monolith to trigger the workflow, probably?)
This wasn't an entirely small engineering org - 300-400+ devs?
I agree, though, is the point. I think folk don't put enough thought into the development story when going this route. I think monorepos are the only sensible way to go about it once folk have cross-service work to accomplish, and monoliths are a _good_ way to build applications for longer than folk give them credit. That said, some monoliths are more productive than others. Slow startup/compilation can destroy productivity.