OK. Let's talk about it.
It's not a technical decision, it's an organizational one.
Microservices were invented by companies with thousands of engineers who needed teams to deploy
independently.
Unless you have that problem, you're importing complexity for free.
As Martin Fowler puts it: almost every successful microservices story started as a monolith that got too
big,
and almost every project that started with microservices from scratch ended up in serious trouble.
→ martinfowler.com
You'll build a distributed monolith.
Without rock-solid service boundaries (which take years to get right), you'll end up with the same tangled
mess ,except now your function calls go over the network. Kelsey Hightower said it best: instead of writing
bad
code
in one place, you end up building bad infrastructure and deploying the bad code on top of it.
→ changelog.com
Even Amazon regrets it.
In 2023, Amazon Prime Video's monitoring team moved from a distributed microservices architecture
back to a single process. The result: 90% cost reduction and better scalability.
Yes, Amazon saved money by not using its own services.
The original blog post has since been deleted, make of that what you will.
→
Archived blog post (PDF)
You don't have Netflix's problems.
Netflix runs over 1,000 microservices on AWS, backed by thousands of engineers
and a decade of custom tooling they had to build themselves (Eureka, Hystrix, Zuul, Conductor…).
You have a team of 4 and a deadline next month. These are not the same situation.
→ Netflix Tech Blog
The tooling will eat you alive.
Kubernetes, Docker, service mesh, API gateway, distributed tracing, saga patterns, circuit breakers…
You wanted to ship a feature. Now you have a platform team.
Congratulations, you're maintaining infrastructure instead of building product.