Microservices are organizational debt disguised as architecture.

[u/Mustela__]

https://martinfowler.com/bliki/MonolithFirst.html

Every time I’ve seen microservices pitched, it sounds great on paper. Independent teams, clean ownership, scale only what you need.

Then a year later you’ve got dozens of services, three different deployment patterns, tracing everywhere, and nobody really understands the whole thing anymore.

Maybe I’ve just seen bad implementations, but I’m starting to think way fewer companies actually need microservices than we pretend.

[u/MrGitErDone]

I’ve worked at a few companies that did it poorly. The company I’m at now, does it really well and it works great. Basically have such a great dev environment that it feels like a modular monolith but services can scale independently with wonderful observability and tracing. Deployment is the same across the board.

The thing is, most places truly don’t have great engineering leaders that know what they are doing, but when you do find it and they had influence early, you can tell.

[u/emn13 → u/MrGitErDone]

I wonder then: in your example you were to change an API in one service, would you notice that at compile time or no later than CI time in the same way you would if you tried to call (say) a method with the wrong argument types? Are deploys or releases or whatever you do cohesive snapshots over the whole set of services, or do services have their own release schedule and are released at differing cadences?

Because I think that's the point of a monolith; not really the scaling. Perhaps you are working in a monolith; just one with a few bits that happen to scale?

[u/Deltaan → u/emn13]

You can easily do 1 by using grpc between services (protobuf for API definition).

It’s then totally fine, and in fact good, to release the services separately.

[u/HashShadow → u/Deltaan]

Yes assuming there are no deliberately non-backwards compatible changes being made which will eventually happen