4 ms·

Placing a network call in your system also introduces: - distributed systems problems - think consistency and ACID - increased refactoring complexity - you no

Placing a network call in your system also introduces: - distributed systems problems - think consistency and ACID - increased refactoring complexity - you now have to change the api three times instead of 1 to deploy the change with 0 downtime - requirements for more generic CI/CD pipelines - you will develop many microservices, it's important to do it fast it's not "just" a network rpc, even technically

Cthulhu_ 3y ago
If it's a network RPC style microservices architecture, you've built a distributed monolith; every service in a proper microservices architecture should be developed, maintained and deployed 100% independently from any other service. If two services are closely tied, they should be merged together. Yes this causes overhead; every microservice will have a public API of sorts that will need to be documented and communicated, and any other service consuming it will need to eventually be updated to keep up with changes. If this overhead is not something your organization can afford, you should not be doing a microservices architecture.
YetAnotherNick 3y ago
> it's not "just" a network rpc, even technically Except is is. Microservice doesn't mean distributed setup. For the first problem, yes service running in multiple pods causes issues, but even monolith could face the same issue. Statefulset based microservices not only exists, but is a pretty common setup. Also I would even call multiple container on the same pod as microservice, which basically solves all of the problem. There are many ways to solve second problem. Some folks create different API version. I prefer different deployment. Last is a problem for monolith. I know of big companies where compile time is in order of an hour for monolith, even for small change.
- 0xbadcafebee 3y ago
  Except it isn't, because a microservice requires an isolated dataset, API abstraction, documentation, versioning, consumer contract, dependency chain, complex release management. It's a radically different design because it forces you to develop the entire system differently to deal with very different abstractions, ways of working, expectations. A distributed monolith is simpler, but simultaneously more buggy than a centralized monolith.

Cthulhu_ 3y ago

If it's a network RPC style microservices architecture, you've built a distributed monolith; every service in a proper microservices architecture should be developed, maintained and deployed 100% independently from any other service. If two services are closely tied, they should be merged together. Yes this causes overhead; every microservice will have a public API of sorts that will need to be documented and communicated, and any other service consuming it will need to eventually be updated to keep up with changes. If this overhead is not something your organization can afford, you should not be doing a microservices architecture.

YetAnotherNick 3y ago

> it's not "just" a network rpc, even technically Except is is. Microservice doesn't mean distributed setup. For the first problem, yes service running in multiple pods causes issues, but even monolith could face the same issue. Statefulset based microservices not only exists, but is a pretty common setup. Also I would even call multiple container on the same pod as microservice, which basically solves all of the problem. There are many ways to solve second problem. Some folks create different API version. I prefer different deployment. Last is a problem for monolith. I know of big companies where compile time is in order of an hour for monolith, even for small change.

0xbadcafebee 3y ago
Except it isn't, because a microservice requires an isolated dataset, API abstraction, documentation, versioning, consumer contract, dependency chain, complex release management. It's a radically different design because it forces you to develop the entire system differently to deal with very different abstractions, ways of working, expectations. A distributed monolith is simpler, but simultaneously more buggy than a centralized monolith.