Microservices was a sort of drop in the bucket point in time moment of 2015-2016 and the term lingers on for a description for what is services development. It'

Microservices was a sort of drop in the bucket point in time moment of 2015-2016 and the term lingers on for a description for what is services development. It's a step change to what SOA was and then Lambda and serverless became the next exploding function after that. There is still definitely merit to that type of development, but within the right context and scale of organisation. See, microservices and services development in general solve organisational problems first, not technical. Breaking out the hot paths in your code to separate services logically only gets you 10 services at best. But when your engineering org is tens if not hundreds of teams, the cross functional dysfunction becomes very apparent and that's where APIs, services and microservices do well. I think like all hot shiny trends, it was taken to an extreme by a lot of people or touted as the hammer to solve all problems. In reality, it best serves orgs bigger than 200 people and scaling rapidly. As someone who spent a decade working on microservices tech, I can vouch for the exhaustion at this point and the desire to go back to a more macro/monolith type of development. Yet still, I understand when and where microservices play a role, the key being, its an evolutionary architecture, you don't just "do" microservices, your org evolves in that direction, and then standardisation plays a huge role. Hence why I wrote a framework for it -> https://go-micro.dev https://go-micro.dev