4 ms·

So use transactions? I don't understand what part of microservices prevents that. In fact, transactions are pretty fundamental to reliable systems. https://www

So use transactions? I don't understand what part of microservices prevents that. In fact, transactions are pretty fundamental to reliable systems. https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf From the abstract: >It is pointed out that faults in production software are often soft (transient) and that a transaction mechanism combined with persistent process-pairs provides fault-tolerant execution -- the key to software fault-tolerance.

nicoburns 4y ago
Well you can't use database transactions across multiple connections, so presumably this would involve you implementing your own transaction and rollback system. That's a lot more complexity than using a system that just works out of the box.
- staticassertion 4y ago
  I don't really understand. If I have a database, and a service is talking to it, it can open a transaction. If I then want to talk to other services, and rollback that transaction based on what happens with those, I can do that. Microservices changes nothing about this. If you want to remove transactions by splitting up your logic such that it operates in terms of sequences or something, you can do that, but that's just a choice like any other.
  - nicoburns 4y ago
    If the other services you talk to mutate state then rolling back those changes is non-trivial.
    - staticassertion 4y ago
      Well... don't do that? This is where microservices comes in. In a SOA architecture nothing really tells you when it's a good idea to split things up. Microservices is a methodology to help you avoid this exact situation. You'd have the same problem in a monolith if you have two different modules working on the same db.
  - dagss 4y ago
    Assume you have two tables A and B on the same DB. They are sort of seen as unrelated. Suddenly a feature request requires that A and B are mutated together consistently. If it is in one service you just use a common DB transaction and get it done. If it is in one microservice for A and one microservice for B then you have to somehow implement this transaction yourself. This is possible but more work.
    - staticassertion 4y ago
      OK imagine that you have two different modules that manage transactions to a database. Now suddenly you need there to be consistent mutations between those functions. Do you see my point? Microservices do nothing here - you have run into antipatterns that are universal, and that microservice architecture addresses explicitly as an antipattern.
      - dagss 4y ago
        I do not see your point. Sometimes consistent mutations between modules is wanted. Monoliths lets you do it. Perhaps you discovered your module boundaries were wrong, you create a supermodule to encaspulate both to coordinate the joint transaction and then split up later a different way and so on. Module boundaries are refactorable. Importantly, what if the alternatives you end up with achieve the same things with microservices end up causing a ball of mud of services, reimplementing transaction logic that belong in your DB in your homegrown network protocols? You seem to say that some things are not possible with microservices and therefore this leads to cleaner code. My retort is that the kind of things one sometimes come up with as workarounds to make things still work for microservices are so complex that the cure is worse than the disease you wanted to cure in the first place.
        staticassertion 4y ago
        > Module boundaries are refactorable. Why are microservices not refactorable? This is the same exact issue in both cases. You designed something for a use case, the use case changed, now your old design isn't working. So maybe you merge those two services, or merge those two modules, or whatever else you want to do. > reimplementing transaction logic that belong in your DB in your homegrown network protocols Don't do that? I mean, again, this issue of "I wrote something the wrong way and now I have to fix that" is not any better or worse in microservices. > My retort is that the kind of things one sometimes come up with as workarounds to make things still work for microservices That doesn't sound like microservices. In fact, even the idea of having a database shared across services doesn't sound like microservices - it's an explicit antipattern. So it sounds like a bad SOA design. The point of microservices is to take SOA and add patterns and guidance to avoid the issues you're talking about.
convolvatron 4y ago
absolutely - if 'microservices' had transactions, it would actually provide some real leverage for fault handling over a monolith
abraxas 4y ago
So distributed transactions with two phase commit, XA and all that. Imagine what, microservices hipsters tried that and it turned out too slow and cumbersome so they invented "sagas" which are still immensely more complex than a single transaction in a single database.
- staticassertion 4y ago
  You seem confused. If you want a transaction use a transaction. If you don't want a transaction don't use a transaction. If you need a transaction across services, that sounds like you've run across a microservice antipattern. Monolith/Microservice changes nothing here - you can have the same issue in a monolith where two different functions are managing transactions and now you want a single transaction. Literally irrelevant.

nicoburns 4y ago

Well you can't use database transactions across multiple connections, so presumably this would involve you implementing your own transaction and rollback system. That's a lot more complexity than using a system that just works out of the box.

staticassertion 4y ago
I don't really understand. If I have a database, and a service is talking to it, it can open a transaction. If I then want to talk to other services, and rollback that transaction based on what happens with those, I can do that. Microservices changes nothing about this. If you want to remove transactions by splitting up your logic such that it operates in terms of sequences or something, you can do that, but that's just a choice like any other.
- nicoburns 4y ago
  If the other services you talk to mutate state then rolling back those changes is non-trivial.
  - staticassertion 4y ago
    Well... don't do that? This is where microservices comes in. In a SOA architecture nothing really tells you when it's a good idea to split things up. Microservices is a methodology to help you avoid this exact situation. You'd have the same problem in a monolith if you have two different modules working on the same db.
- dagss 4y ago
  Assume you have two tables A and B on the same DB. They are sort of seen as unrelated. Suddenly a feature request requires that A and B are mutated together consistently. If it is in one service you just use a common DB transaction and get it done. If it is in one microservice for A and one microservice for B then you have to somehow implement this transaction yourself. This is possible but more work.
  - staticassertion 4y ago
    OK imagine that you have two different modules that manage transactions to a database. Now suddenly you need there to be consistent mutations between those functions. Do you see my point? Microservices do nothing here - you have run into antipatterns that are universal, and that microservice architecture addresses explicitly as an antipattern.
    - dagss 4y ago
      I do not see your point. Sometimes consistent mutations between modules is wanted. Monoliths lets you do it. Perhaps you discovered your module boundaries were wrong, you create a supermodule to encaspulate both to coordinate the joint transaction and then split up later a different way and so on. Module boundaries are refactorable. Importantly, what if the alternatives you end up with achieve the same things with microservices end up causing a ball of mud of services, reimplementing transaction logic that belong in your DB in your homegrown network protocols? You seem to say that some things are not possible with microservices and therefore this leads to cleaner code. My retort is that the kind of things one sometimes come up with as workarounds to make things still work for microservices are so complex that the cure is worse than the disease you wanted to cure in the first place.
      - staticassertion 4y ago
        > Module boundaries are refactorable. Why are microservices not refactorable? This is the same exact issue in both cases. You designed something for a use case, the use case changed, now your old design isn't working. So maybe you merge those two services, or merge those two modules, or whatever else you want to do. > reimplementing transaction logic that belong in your DB in your homegrown network protocols Don't do that? I mean, again, this issue of "I wrote something the wrong way and now I have to fix that" is not any better or worse in microservices. > My retort is that the kind of things one sometimes come up with as workarounds to make things still work for microservices That doesn't sound like microservices. In fact, even the idea of having a database shared across services doesn't sound like microservices - it's an explicit antipattern. So it sounds like a bad SOA design. The point of microservices is to take SOA and add patterns and guidance to avoid the issues you're talking about.

convolvatron 4y ago

absolutely - if 'microservices' had transactions, it would actually provide some real leverage for fault handling over a monolith

abraxas 4y ago

So distributed transactions with two phase commit, XA and all that. Imagine what, microservices hipsters tried that and it turned out too slow and cumbersome so they invented "sagas" which are still immensely more complex than a single transaction in a single database.

staticassertion 4y ago
You seem confused. If you want a transaction use a transaction. If you don't want a transaction don't use a transaction. If you need a transaction across services, that sounds like you've run across a microservice antipattern. Monolith/Microservice changes nothing here - you can have the same issue in a monolith where two different functions are managing transactions and now you want a single transaction. Literally irrelevant.