As it is so often the case, the choice between monolith and microservices is not a binary one; rather, it is a sliding scale between two extremes. On one end w

As it is so often the case, the choice between monolith and microservices is not a binary one; rather, it is a sliding scale between two extremes. On one end we have a real monolith: a single executable binary, with no external dependencies apart from the OS bindings. This is very rare in practice, and most commonly found in games and probably mobile apps; when it comes to Web-based services, even a traditional idea of single-codebase app usually has a SQL database as an external dependency. On the other end of the scale there is a complex system consisting of hundreds or even thousands [0] of tiny services that require complex orchestration mechanisms such as a service hub or service mesh. So each team (in a wide sense: could be a company, organisation, department etc) needs to consider where they fall in the continuum, considering a) which architecture will provide most benefit while b) still being maintainable by the team; both the architecture and the team need to evolve together. [0] https://qconlondon.com/london2020/presentation/monzo https://qconlondon.com/london2020/presentation/monzo