[kgeist]

A few years ago, after having worked on a microservice-oriented project for some time, I joined a team which developed a monolith. To be honest, it felt like a breath of fresh air. What previously took coordination across multiple teams and repositories, tens of API schemas, complex multi-stage releases (your average feature usually touches lots of microservices), complicated synchronization of data stored in tens of DB, with a whole theory on microservice communication and a whole DevOps team with their own "platform" -- now it's just a bunch of commits in the same repository, a single release. To prevent code from becoming complex spaghetti, they simply use the modular monolith architecture (modulith). There's simply a linter which makes sure module boundaries are not violated (so they are encapsulated properly, just like in microservices). Want to support more load? Just increase the number of workers/servers. The single DB becomes too large? Just split it into several DBs and connect to different physical machines as needed. Now I'm pretty skeptical of the whole microservice thing. To be honest, I can't name a single advantage microservices over monoliths anymore. All problems are solvable with a monolith just fine, without all the complexity. The only time we needed to physically split a part of the monolithic codebase into a separate repository was when the infosec department asked us to store and process personal data inside isolated infrastructure to conform to some regulations.