Instead of arguing against microservices, it would be better to ask the team to plan out solutions to the hard problems associated with microservices, namely th

Instead of arguing against microservices, it would be better to ask the team to plan out solutions to the hard problems associated with microservices, namely the hard problems associated with distributed systems. Things like: * How will transactions across multiple services be handled, and as a followup, how will rollbacks happen when an error happens mid-transaction * When all the data is distributed across multiple service DBs, how consistency be enforced? What happens when data is no longer consistent (e.g. data in one DB references data in another DB that is no longer there, or has been updated)? * [basically, how will anything related to ACID be handled when you no longer have a single ACID DB?] * How will errors be handled with various permutations of individual services being unavailable? If a single service going down brings down the site, has anything really been gained? * How will distributed logging be done such that bugs can be tracked down in production. How will a given single request be tracked across services? * How will automated tests be written when everything is now a network call instead of a function call? Mocking out all the things gets old fast and introduces its own set of problems relating to testing code that isn't the actual production code. * How will API versioning be handled for each service, especially if different services are being built in silos by different developers? If they have solutions for things like this, great! If not, perhaps they should before pushing forward.