Microservices vs Monoliths

It shows that microservices come with a lot of complexity. Only do it when your team is growing bigger and there are problems in building your app with a big team. split up the teams, and split up the services. Let teams deploy the services.

Not that many companies actually need microservices. Consider going back to a more monolithic setup

Microservices, in my experience, are chiefly about scaling teams (more freedom to move faster). In fewer cases, it is about optimizing a hot path. If it is not one of those, I'm having a hard time seeing why you would want the overhead of microservices.

Why would you consider microservices if you are only 12 developers?

Agree - the biggest gain microservices give you is they allow many-teams to make progress together. If you don't have many teams then the overhead may not be worth it.

Microservices were/are an attempt of standardizing software development practices at really large organizations.For example: your typical big bank has hundreds or thousands of teams (both internal and through professional services companies) developing all kinds of applications under different technologies/hardware.In this case due to domain/organizational scale it is not feasible to have a mono repo (or 2, or 3) with a giant codebase.And as a result the typical situation

Microservices can be useful in medium/large companies where you have many teams of devs and it becomes cumbersome to have them all work on one monolith. As long as there's good communication and understanding of needs between teams, each team can develop their services how they want, in whatever language/platform, with their own review and QA and deploy processes.For smaller teams or small projects it isn't really super useful. Also, my personal experience is that when you

Microservices are a solution to organizational problems, not to technical ones. They mean accepting increased technical complexity (your system is now distributed) in exchange for decreased organizational complexity (your teams can now deploy independently from each other, can safely make database schema changes, etc).Going with microservices from day 1 will initially mean that you have one team maintaining many services. They have to deploy them separately. If you're doing

it depends on your reasons.- if you need to scale the number of teams working on the same product you need to introduce microservices to make the teams work independently from each other.- if you need to scale the (monolith) service and it is too expensive to just scale it n times. microservices can help because you can scale each microservice independently.- that's said the overhead is real. There have been quite a few publications and advocates (like Randy Shoup) that staying mon

Microservices are there because of Conway's Law.If you have a small team that takes care of all aspects of the system, microservices will cause you plenty of headache. It is usually better to keep things simple, as a monolithic system built using technologies that all the developers are familiar with.If you have a large, multidisciplinary team, microservices will allow you to split the team into smaller squads focussed on individual components and develop and deploy them independently