This is purely anecdotal, but I feel like developers who have worked on monoliths with terrible teams tend to fall in love with the microservices approach because as long as the endpoint is stable, it doesn't matter what's going on underneath the hood. On the other hand, developers who have worked on microservices with good teams tend to think that microservices are too complex and unwieldy.
I work in finance and we have a similar setup. We have a platform type of app and many different teams working on different products. Each team is responsible for its own part, from JS web components to the Java backend micro services. There are of course teams responsible for building the portal out of the many components, orchestrating the backend of microservices, etc. It does allow teams to work and release independently.
At some point in the development of a large app you run into irreducible complexity. The logic and moving parts are just necessarily complicated and nobody is going to fully understand the system. It doesn’t matter what architecture you use, hard is hard. I think people tend to forget this and build a house of cards trying in vain to correct it.
Okay, but there are a lot of ways to split up & scale projects and teams besides microservices. What's needed is a guide for scaling that considers all the common options and their tradeoffs, and how to measure those tradeoffs against your own shop.
They link to another blog article that say:
> The monolithic approach doesn’t work for larger web apps
> Having a monolithic approach to a large front-end app becomes unwieldly.
But in my opinion breaking up the frontend (or backend for that matter) they way that they say you should is much more "unwieldly".
Seriously, is there any benefits at all? Job security?