3 ms·

If you are doing transactions across Microservices you have done "Microservices" incorrectly. Divide your microservices along business, not technical, concerns.

If you are doing transactions across Microservices you have done "Microservices" incorrectly. Divide your microservices along business, not technical, concerns. While Microservices themselves can/should absolutely use transactions internally, they should be coarse grained actions. A call into a microservice should either fail and complete, but never leave a system in a partial state.

wg0 3y ago
And... How that is possible? When you want multiple atomic operations from multiple Microservices to fail altogether or not because there's a workflow that needs those steps?
- foobazgt 3y ago
  There are all sorts of examples of this in the real world, because it's often not feasible to group everything you'd like into a single transaction. As a trivial example, consider any interaction with a third party. Once you're into that territory, you're talking logs, asynchronous retry queues, compensating operations, etc. Sometimes the surface area of your company's product gets so large that, in order to scale, you interact with other teams as if they were 3rd parties.
  - wg0 3y ago
    We are not talking about third parties. Microservices are always first party, all that you own or some other team within your organisation owns even if they get deployed onto different clouds or something. Easier would be to admit that the microservices idea was the biggest fad in the history of computing and milked by consultancies to no end while compounding the complexity of software development to unprecedented levels, needlessly.
rqtwteye 3y ago
Is there a process for figuring out how to do microservices “correctly” by your definition? It seems incredibly difficult to stay correct while requirements are being added.
- colonwqbang 3y ago
  The fact that people like Prof. Leymann are writing whitepapers on how to do microservice "incorrectly" the best way, speaks to this.
- JamesBarney 3y ago
  I think most companies do this pretty well when deciding what projects different teams are responsible for. Those are usually pretty good business joints to cleave the domain. People just lose their mind when you say the microservice.
- mjfisher 3y ago
  Yeah - start with a monolith as Martin Fowler (the guy who popularized microservices) suggests. Split out services as you understand more about how the business is developing and stabilising.
  - rqtwteye 3y ago
    So basically don’t do micro services unless there is a real need :-). I am on board with that but I am old and don’t understand how modern software gets done.
hinkley 3y ago
Business concerns change every month. Where is your architecture now?
- winrid 3y ago
  I can assure you some of us have worked in hellscapes where it does change every month ^_^
  - abwizz 3y ago
    probably most
  - hinkley 3y ago
    I had a guy early on who tried to change the business plan every week. A few times that was twice a day. It was exhausting.

wg0 3y ago

And... How that is possible? When you want multiple atomic operations from multiple Microservices to fail altogether or not because there's a workflow that needs those steps?

foobazgt 3y ago
There are all sorts of examples of this in the real world, because it's often not feasible to group everything you'd like into a single transaction. As a trivial example, consider any interaction with a third party. Once you're into that territory, you're talking logs, asynchronous retry queues, compensating operations, etc. Sometimes the surface area of your company's product gets so large that, in order to scale, you interact with other teams as if they were 3rd parties.
- wg0 3y ago
  We are not talking about third parties. Microservices are always first party, all that you own or some other team within your organisation owns even if they get deployed onto different clouds or something. Easier would be to admit that the microservices idea was the biggest fad in the history of computing and milked by consultancies to no end while compounding the complexity of software development to unprecedented levels, needlessly.

rqtwteye 3y ago

Is there a process for figuring out how to do microservices “correctly” by your definition? It seems incredibly difficult to stay correct while requirements are being added.

colonwqbang 3y ago
The fact that people like Prof. Leymann are writing whitepapers on how to do microservice "incorrectly" the best way, speaks to this.
JamesBarney 3y ago
I think most companies do this pretty well when deciding what projects different teams are responsible for. Those are usually pretty good business joints to cleave the domain. People just lose their mind when you say the microservice.
mjfisher 3y ago
Yeah - start with a monolith as Martin Fowler (the guy who popularized microservices) suggests. Split out services as you understand more about how the business is developing and stabilising.
- rqtwteye 3y ago
  So basically don’t do micro services unless there is a real need :-). I am on board with that but I am old and don’t understand how modern software gets done.

hinkley 3y ago

Business concerns change every month. Where is your architecture now?

winrid 3y ago
I can assure you some of us have worked in hellscapes where it does change every month ^_^
- abwizz 3y ago
  probably most
- hinkley 3y ago
  I had a guy early on who tried to change the business plan every week. A few times that was twice a day. It was exhausting.