3 ms·
> don't distribute your objects I guess people writing microservices or services connected via the Internet didn't get the memo.
by sph 2y ago
> don't distribute your objects
I guess people writing microservices or services connected via the Internet didn't get the memo.
- mort96 2y agoMicroservices aren't about distributed objects, they're about small services which communicate via explicit IPC (such as HTTP or gRPC).
- dayjaby 2y agoThe author of that rule explains that (well-crafted) microservices don't disobey that rule: https://martinfowler.com/articles/distributed-objects-microservices.html https://martinfowler.com/articles/distributed-objects-micros...
- cjk2 2y agoI spend all day every day working with those. I have yet to find a single microservices architecture that could not be solved cheaper and simpler in some other way with less side effects. Plus there are some disparity between APIs and object distribution. (Note I only work on non-google scale stuff where it is probably appropriate) Edit: good example recently, I saw one where they implemented a complex distributed reservation pattern across microservices that gets about 100 transactions a day. They could have done it in one process with proper transaction isolation in a DB fine for about 1/100th of the total cost.
- XorNot 2y agoHonestly the rule I put on it nowadays is, if it doesn't have a logical boundary within the organization then it doesn't need to be a separate service. If you have 6 microservices and they're all being maintained by the same team of developers, you don't need 6 microservices. At most, I would grant maybe 2 - and that's simply because usually once something like payments and credit card handling get involved, for compliance reasons you want to really not touch it unless you have to - but that's still an organization boundary, just a self-imposed/PCI compliance based one.