4 ms·

Good grief, the three examples sound like a project I am working on.. I have a feeling that microservices are the new OOP, just a layer higher. Just like in OO

by js8 7y ago

Good grief, the three examples sound like a project I am working on.. I have a feeling that microservices are the new OOP, just a layer higher. Just like in OOP, where you keep data in lots of tiny objects, you keep the data across a bunch of little databases instead of a big central one. It is a very seductive idea (and as Alan Kay explains, inspired by biology), unfortunately, it is really not that useful for designing real-world computer systems, where we want data to be consistent and aggregate them in different ways.

dkersten 7y ago
> it is really not that useful for designing real-world computer systems, where we want data to be consistent I believe it was "Life Beyond Distributed Transactions"[1] that showed an alternative approach that often works without providing globally consistent data. I've done a few thought experiments in the past, where I tried to design some systems without transactional consistency. Its not necessarily easy, but it often (although, I assume not always) can be done. Whether the extra effort is worth it or not, depends on your specific needs and goals, I guess. [1] https://queue.acm.org/detail.cfm?id=3025012 https://queue.acm.org/detail.cfm?id=3025012
- js8 7y ago
  I think this is a very different approach than microservices. You're not sidestepping the problem of consistency, you're aware of the trade-off.
  - dkersten 7y ago
    Well, you're designing around the limitations of not having consistency. But yes, its not really related to microservices.
joeblubaugh 7y ago
In many real-world distributed systems, you actually trade off data consistency for scalability or the ability to independently change components among engineering teams. I would argue that if you need strong consistency in very large datasets, distributed designs should more often be "sharded" designs where strong consistency is maintained in data shards and not necessarily between data shards.
- js8 7y ago
  I think I don't have a problem with inconsistent shards. My point is, I think, more about the consistency of the data schema rather than the actual data. (You could also say that inconsistency is bearable as long as you can describe it.) It's similar to a debate in OOP vs. FP about encapsulation. In OOP, data (schemas really) are hidden from other objects (services). In FP, data are "naked" and visible to everyone. So the FP approach forces you to deal with the changes to the schema (which are often a consequence of resolving inconsistencies) on global level. OOP doesn't and it is eventually going to bite you.

by js8 7y ago

dkersten 7y ago

> it is really not that useful for designing real-world computer systems, where we want data to be consistent I believe it was "Life Beyond Distributed Transactions"[1] that showed an alternative approach that often works without providing globally consistent data. I've done a few thought experiments in the past, where I tried to design some systems without transactional consistency. Its not necessarily easy, but it often (although, I assume not always) can be done. Whether the extra effort is worth it or not, depends on your specific needs and goals, I guess. [1] https://queue.acm.org/detail.cfm?id=3025012 https://queue.acm.org/detail.cfm?id=3025012

js8 7y ago
I think this is a very different approach than microservices. You're not sidestepping the problem of consistency, you're aware of the trade-off.
- dkersten 7y ago
  Well, you're designing around the limitations of not having consistency. But yes, its not really related to microservices.

joeblubaugh 7y ago

In many real-world distributed systems, you actually trade off data consistency for scalability or the ability to independently change components among engineering teams. I would argue that if you need strong consistency in very large datasets, distributed designs should more often be "sharded" designs where strong consistency is maintained in data shards and not necessarily between data shards.

js8 7y ago
I think I don't have a problem with inconsistent shards. My point is, I think, more about the consistency of the data schema rather than the actual data. (You could also say that inconsistency is bearable as long as you can describe it.) It's similar to a debate in OOP vs. FP about encapsulation. In OOP, data (schemas really) are hidden from other objects (services). In FP, data are "naked" and visible to everyone. So the FP approach forces you to deal with the changes to the schema (which are often a consequence of resolving inconsistencies) on global level. OOP doesn't and it is eventually going to bite you.