5 ms·
I quote Fowler's ancient First Law of Distributed Object Design: "don't distribute your objects". Any distribution results in masked complexity and many hard t
by cjk2 2y ago
I quote Fowler's ancient First Law of Distributed Object Design: "don't distribute your objects".
Any distribution results in masked complexity and many hard to reason about scenarios even if the language or platform supports it transparently.
Ergo, just because you can doesn't mean you should, unless you want to discover them all, usually at an inconvenient point in the future when everything is broken and there's cash bleeding out of your org somewhere.
- 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.