I agree to not start with microservices.. But its better to not wait too long after the project is growing. Regarding his points: - Infrastructure requirement

I agree to not start with microservices.. But its better to not wait too long after the project is growing. Regarding his points: - Infrastructure requirements: You don't need all that stuff! You can have multiple services run on PaaS services / Cloud Run, and you dont need to deal with all the kubernetes stuff. Even if you prefer K8S, then you still dont need a service mesh from the start. Datadog and Gitlab brings you very far with hardly any work on your side. - Faster Deployments My point: 80 microservices? Crazy .. Why? Just have a service per business domain, and try unifying the CI/CD stack. We had 1 big Monolith which would deploy 5 times per day, buy every deploy took around 1 hour. Having 5 to 10 services, that all deploy within 5 minutes is so much nicer to work with. - The Supporting Culture This is important: Architecture follows company organization, and vice versa. Every team often owns 1 or 2 services. Teams should be organized by domain. Business boundaries should be agreed upon in a higher level. Sitting in your dev corner, building services without talking and aligning with the Product owners & MT is a recipe for distaster imho. The services should solve a problem that PO's understand. You should have alignment. - Better Fault Isolation We never said it was going to be easy... It requires a different way of building your system. You need to think distributed systems.