Don't start with microservices – monoliths are your friend

There are actually some patterns to deal with this, such as Saga - I'm actually working on a project (not open-source yet) related to this specific problem. You can reach me at can@hazelcast.com if you want to learn more.

> Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart.

And, this is not necessarily a bad thing.

Modules have higher requirements for self discipline the services. Precisely because the boundaries are so much easier to cross.

And also because it is harder to guard module from changes made by other teams. Both technically and politically, the service is more likely to be done by a single team who understands it. Module is more likely to be modified by many people from multiple teams who are just guessing what it does.

Microservices doesn't necessarily mean K8S running on self-managed compute instances as in the example given in the article.

The main mistake of the article is that the premise is "microservices" but then the examples are about infrastructure (K8S etc), but the 2 things are not tied, you can have that same architecture cited in the article running monolith instances for example, and it would be every bit as complex as managing the micorservices example, without any of the advantages.

Fully managed serverless solutions like Lambda/Cloudflare Workers/etc, managed through SAM or Serverless Framework solves most of the problems cited in the article.

The whole infra in our case is API Gateway + Lambda + DynamoDB, this infra is not more complex to manage than our old monolith which was on ALB + EC2 + RDS.

Deployment is one "sam deploy" away (done in Github Actions), this is actually even simpler than our previous monolith.

Here's my take on microservices: It's a form of modularization. Like all modularization it can be useful to uncouple larger parts of a system - to enforce an architecture, avoid unintended cross-dependencies, make explicit the dependencies that are intended, to allow teams to work more independently, and to allow the different parts of the system to be be developed, compiled, built, deployed (and sometimes scaled) independently.

But all this comes at a cost - you have to know where the module boundaries are, because moving these is much harder. The flexibility that you've gained within each module comes at the cost of making it harder to move the border between modules. It's very easy to put down a module border in the right spot, and you make a refactor (needed for cleanup or performance improvement) go from tricky to impossible. E.g. that piece of info needed in this module now canonically lives in the other one. Or we accidentally add a couple N's to the time complexity of an algorithm that works on data in multiple modules.

But getting the borders right on the first try is hard, unlikely even. Where those borders should be depends on a lot of things - the user domain, the performance characteristics, the development team(s) (Conway's law and all that) and the ways in which the business requirements change. For that reason, I think most successful modularizations are either done by breaking down an existing monolith (providing these insights) or by basing it on a known running system that is "close enough" in its needs and environment.