> But I did work at a company that decided to implement microservices a la Amazon, even going so far as sharing Bezos' famous 2 pizza team memo. This effect essentially happened over night. As people spun up more and more microservices, things got more and more siloed, cross team collaboration was significantly more difficult, and things became an increasingly more complicated rube goldberg machine that just destroyed people with on call schedules.
Micro services solve a problem for companies that have already reached a certain scale were cross team communications have become unfeasible and now communicating by well defined API contract is a better choice.
Also ideally micro services should reduce the blast radius of outages. If an outage is not easily traced to what team is root causing it, then proper monitoring is not in place.
Sure I've had times where on call went off and it wasn't my team's fault but it was no more than 10 minutes to determine that and reroute the call and then to back to sleep.
The other fact is that when designing a new microservice it should be done in conjunction with the primary consumers of that service just like designing any other part of software. Stakeholders need to be brought in and consulted.
The advantage of microservices is that new code is only going to impact direct consumer s and downstream services.
It also allows you to upgrade a service in place or completely rewrite it so long as you adhere to the original contract.
I've seen impressive rollouts of security updates across a huge code base that was only possible because of a microservice-based design.
I've seen giant monoliths fall apart as multi-year long efforts are undertaken just to update the build system.
The hard part of a microservices is they require discipline in an organization and basically assigning an engineer for 1 to 2 weeks to write run books and add monitoring.
Of course, those runbooks should be written no matter what paradigm someone uses!