Very interesting talk, but set playback to 1.25x speed. It transforms this talk.

@michaeleaster1815

4 жыл бұрын

1.25x transforms all talks (!), usually for the better

@nallap6566

4 жыл бұрын

Well tbh even 1.5x...sooner the better..when the speaker is too slllll000wwww..

@aldebaranh666

4 жыл бұрын

1.75x no prob

@burstingfist

4 жыл бұрын

Nah, 2x is the new 1.25x

@MrMikomi

4 жыл бұрын

2x is better.

Agenda [3:58] ACID is not an option [5:04] (Scenario: Customer has a credit limit) [5:13] Transactions in a monolithic architecture [5:58] Concurrent transaction for the same customer will be serialized [7:15] Microservices [9:00] Microservice architecture [10:30] Loose coupling = encapsulated data [11:13] 2PC is not an option [13:41] Overview of sagas [15:01] Use Sagas instead of 2PC [15:14] Create Order Saga [16:22] Rollback using compensating transactions [18:20] Saga: Every Ti has a Ci [19:08] Create Order Saga - rollback [20:30] Sagas complicate API design [22:03] Request initiate the saga. When to send back the response? Option #1: Send response when saga completes - Response specifies the outcome - Reduced availability Option #2: Send response immediately after creating the saga (recommended) - Improved availability - Response does not specify the outcome. Client must poll or be notified Revised Create Order API [24:41] createOrder() returns id of newly created order NOT fully validated getOrder(id) called periodically by client to get outcome of validation Minimal impact on UI [25:22] UI hides asynchronous API from the user Saga will usually appear instantaneous ( UI displays "processing" popup Server can push notification to UI Sagas complicate the business logic [26:33] Coordinating sagas [28:33] How to sequence the saga transactions? [28:41] After the completion of transaction Ti "something" must decide what step to execute next Success: which T(i+1) - branching Failure: C(i-1) Option#1: Choreography-based coordination (distributed) [29:45] Option#2: Orchestration-based coordination (centralized) [30:16] Saga orchestrators are state machines [30:48] Implicit vs. explicit orchestrator [31:47] Event-based, implicit orchestrator [32:38] Explicit orchestration [34:05] Create Order Saga (code sample) [35:12] Initializing the saga [37:20] Handling a reply [37:58] Customer Service - command handling [38:28] Transactional messaging [39:18] About Saga orchestrator ⇔ participant communication [39:22] Messaging channels [40:52] Create Order Saga messaging [41:31] Messaging must be transactional [41:59] 2PC still isn't an option [43:06] Use database table as a message queue [43:22] Publishing message using polling [44:33] Transaction log tailing [46:17] About transaction log tailing [46:57] MySQL master-slave replication protocol DynamoDB table streams Summary [48:13]

@enkaypeter9313

3 жыл бұрын

Indeed, not all heroes wear capes.

I incorporated a company in 2007 who's goal was simply to proclaim the wonderfulness of MicroServices. Since (and before) then, I have never seen such a flawless talk related to MicroServices. Every other "concern" about distributed systems, Service-Oriented Architecture, Statelessness, Events, Administration, Security, and so forth have all been so mundane. And frankly, all of those other concerns can be mocked out in fairly generic frameworks. This talk touches on the actual MEAT of Software Development which is different for every customer and is the actual fun challenge. It may be stuff that experienced MicroService people know, but it has never been spoken so eloquently. I appreciate this talk very much.

@thechargeblade

3 жыл бұрын

Exactly, a lot of talk just cover from the perspective of technology, sure Microservice is technically a better way to design a system, but when it comes to implementations data is number one priority.

excellent, I have looking for something like this for days. really thanks to Chris Richardson

I readed alot about Saga design pattern and I developed two years a system than implement Saga design pattern and I still learned new things from this video. Thank you.

@morespinach9832

3 ай бұрын

How did you do things differently from a stored procedure?

Actually I'm readying that book. very informative book!

Great Speaker! Knows how to simplify ideas.

I'd only add some minute or two about idempotency in some key moments of the process. Despite of that, this is an excellent talk.

Great talk, one thing I realized after this talk is that 2PC is an option.

@morespinach9832

3 ай бұрын

As are stored procedures from 30 years ago.

This is a real talk on real use cases on real problems

Very well explained! Thanks!

Great speaker , articulate and simplifies the concept

really pragmatic talk. thank you!

Very interesting talk! One question I had near the end of the talk - it seems like using the DB’s change log as the mechanism to publish to the message broken has a large drawback: it tightly couples the internal DB scheme to the API a service exposes to the Saga (which defeats one purpose of microservices, since you want to avoid leaking your DB). I didn’t quite follow why having each individual service coordinate a 2PC between its own DB and a message broker was problematic. This seems much less bad than using distributed TXNs to implement the entire Saga, since the 2PC is an implementation detail of each service. The only single point of failure is the message broker, and I think this is true regardless of your approach?

Old wine in new bottle. I have been doing this design pattern of State Machine Orchestrator in my SOA EDA , with compensating transactions to rollback what services had done till the point of failure. The failure event is either broadcast to all the services or to the Orchestrator so it can co-ordinate the cancellation. As I listened to the talk it was like going through my design document. Message table to message broker has a drawback when the load is high. As it is DB spefic to pull data out to push on message broker it introduces a bottleneck in the DB. Ideal for this is using a distrbuted cache DB or like he mentioned the replication and use the replicated data to message broker. Excellent talk. It touched all the touchpoints Newbies to Micorservices without much experience may think this is something rocketscience, but it as been there for long in a different avatar.

@morespinach9832

3 ай бұрын

What orchestration engines do you recommend? Stuff like camunda?

This was great 👍 . Very easy to follow.

It's been really informative demonstration about how the Saga works entirely, when it comes to publish a message to the message broker (queue) in order to make them transactional , we can design them to get ACK back then consider it as done thus give it a go

Excellent talk. Learned a lot. Thanks

Had already been implementing this principle in some of my designs before learning that it had a name . what a saga :D

@alexknn15

3 жыл бұрын

GarriAndOkroSoup same thing, implemented basic idea like 7 years ago but with 2pc inside each step of saga to save data and send to the next message queue:)

@skipdigit

2 жыл бұрын

Agreed. Been building these types of solutions like 10 years ago. Now it has a name.

Great talk, like that you explained very important part as processing data and sending event atomically. Other resources usually do not explain this important part. But I want to mention one moment, as usually messaging systems guarantee “at least once” delivery, we have to think about idempotency. And if we implement it, we don’t need complicated atomic save and send mechanism anymore, we now can save data and then try to send message to the next queue and ack/commit current queue. For example If we have server failure after saving to DB and before sending to next queue and acking current, then the other instance will get and process current message (here idempotency come into play as we already saved data to DB and another instance will do the same processing cycle with the message - save to db and send to next queue)

@avinandanbanerjee9568

2 жыл бұрын

won't the other instance not send to the other queue, as it fails when saving to db? so we have at most once.

Thx for the upload, good stuff.

Very good explanation of the concepts.

surprisingly interesting talk and could really relate. great learning reference

13:08 correct me if I'm wrong but that transaction example with a single database doesn't work unless you have specified a serialized isolation level (one cpu core to execute all transactions). Otherwise it suffers from write skew even with Snapshot Isolation transaction isolation level which is by default I guess on many relational DB systems. You still might have two transactions that would confirm that there is enough credit at the same time, and at the same time execute insertion of two new orders.

Great talk. What I understood from this talk is microservice consideration and implementation have to be chosen very carefully. Otherwise a perfectly running system that maintains ACID can be runied in a very short period. I guess microservices are good when a system with low transaction volume can be refactored to be cloud native.

@khaledalothman4314

4 жыл бұрын

Microservices are good when the granularity is big enough to avoid ACID properties across services are not needed, yet the microservices architectural benefits can still be realized at that higher granularity.

Hi, i understand that 2PC is out of the scope between two microservices, but inside a single microservices you can use it. For example when you have to write a record on DB and send a message to a broker to start another micorservice.

great talk, got a lot of useful information

Nicely explained, Thank you.

Thank you very much

The Saga and Outbox implementation remind me a lot of NServiceBus.

Great talk. Really useful

Thanks!!!

A masterclass! Thank you.

Do I have any advantage of using a message broker when using a message table unless I want to fan out my messages?

His microservices talks are the most informative and concrete out of anything else I've watched. Definitely getting the book! There's also a lot of information on his website ➠ microservices.io

Awesome.. really good. Thank you :)

Thanks for sharing

With 2x speed, it's a very knowledge 25 minutes talk!

Great talk. Learned a lot. Question, at 29:50, isn't it a bad idea to use choreography under any circumstance since it no longer loosely couples microservices (which is one of the main benefits of a microservices architecture)? I know he mentions the following centralized approach which is better. But what I'm curious about is, "shouldnt one avoid (at all costs) doing choreography and not even say that is a viable option in the first place?"

@kevinkkirimii

5 жыл бұрын

There are situations where choreography works better than orchestration especially for systems that produce events that need not to be executed sequentially.

Excellent, it took last 15mints to understand 1hour repeat and see. Its 4 years before, now i want to see what are latest changes or implications update in saga, any suggestions?? Please replay to comment

Good and clear presentation. Nice talk. I am surprised about using tables for recording messages. If you are using Saga coordinator then it could be the one verifying that an operation was successful and generate message for the next operation.

@austecon6818

2 жыл бұрын

But the sending of the message needs to also be atomic... usually at-least-once-delivery + idempotent consumer is the golden rule there... Can only be achieved (simply) by committing pending messages to local db in a local atomic tx with the new state change... then retrying to send the message until the consumer ACKs.

nice talk by Satya Nadella

I feel like "Saga Orchestration" is completely against the logic behind the microservices which is building independent components and teams. In this scenario a team has to maintain the orchestration point of two services which also has to be aware of the business logic of both services. I know sometimes orchestration is inevitable but I think in this situation it's better to use choreography.

@8Trails50

3 жыл бұрын

I agree. It seems like if you need to pull this out, something has gone wrong.

@user-qv3tu3gi3f

2 жыл бұрын

In fact saga orchestrator became distributed transaction manager

@willd1mindmind639

2 жыл бұрын

The example he is using is a bad one for the principle he is illustrating. Financial processing has always been the epitome of transaction processing in computing. And in modern web commerce you want the customer to know in real time when a payment fails. In that case, the payment service or credit service is a completely separate and independent application, often provided by a third party outside of the organization and there is no coupling directly between that service and the order service. The orchestration is done from the web client so that it can display the response from the payment service to the customer directly. You don't want that to be stuck in some asynchronous message loop after the customer has already placed the order.

@ramonennik2536

6 ай бұрын

Well I do not agree, actually all the payment gateways I had to implement in the past were always working with an async backend call to update the payment status so unless that message arriverd earlier in the backend then you couldn't tell if the payment was really successful on the thanks page

Chris the way you are referring to implicit orchestration through events, I am confused then what is choreography?

Thanks buddy :D

Not sure I get it. How is this not just a distributed transaction where you've added the concept of compensating actions.

This is dope 😍

Good presentation and still this is just showing one aspect chipping off the iceberg. Moving from a monolith to distributed remote services really introduces a ton of complexity and impacts latency. Done badly, and most of them will be, companies move from one ball of mud to another. Its when something goes wrong that is the killer... and you have to scramble around for a magnet to find the needle in a haystack. There are still lots of companies that haven't matured in terms of building and packaging services for a monolith, let alone scaling that to a distributed service architecture which isn't any easier. Lots of opportunities for IT staff in the coming years. I still think that modelling vertical slices based on "entities" is a mistake in presentations. Customer or even order, for example, means completely different things to different roles in an organisation.

Great talk! One question though: If you use a DB table to buffer the messages to be sent to the message broker, haven't you just moved the problem of exactly-once-delivery? What if the mechanism that dispatches the messages from your table to the broker crashes/rolls back?

@Autumn4_love_your_

9 ай бұрын

In this case we first publish message to broker and after that we delete raw with that message. In case when we go down between - we sent message twice but with same idempotent token that must be in table. Its called transactional outbox google it if you want to learn more

That opening was nuts!

@deathmachine808

6 жыл бұрын

No it wasn't bro.

Really enjoyed the talk, but imagine if they these talks used a richer language like F#, Rust, Scala, etc that have enums and traits instead of all the class based fluff ❤

Great talk! I hope Sagas don't manifest themselves as ServiceBus. Whereas Sagas are some state machine implementation, people would abuse them until it becomes another ball of mud. I would rather prefer microservices to be along the following lines: - Define your bounded context well so that they are relatively independent and will have consistent state within the context - If you must have other services decide a consistent state (those shouldn't be lot if you have followed the above), rely on synchronous calls to other services. With next generation protocols like gRPC performance impact is negligible - Leverage service mesh framework like Istio for coordination

@hydtechietalks3607

4 жыл бұрын

Thank you sir, great insights!!

These are very old and good known problems of any distributed system. Main point is when you go from monolith to microservoces you go from single instance to distributed with all of its problems and complications.

how awesome would it be to get an architectural/code review from Chris Richardson?

the money transfer case, I think this kind of function should be designed as in one microservice and done inside a single DB transaction. If there is no option to do so, then probably an intermediate cash pool (fake, intermediate account) is needed

@andyliu1210

9 ай бұрын

That's why in most bank accounts, there is a "reserved" state before it really goes off someone's account.😊

one alternative approach to the deleting the messages in the message table is : 1. mark the processed messages as processed = 1 2. select only those messages for which processed = 0 and order them according to the timestamp

@benhook1013

4 жыл бұрын

Would still have the issue where transactions that start in one order may get committed to the table in a different order (i.e. timestamp of 2nd transaction may be before timestamp of 2nd transaction's message), which is a problem if you want to continue processing them in the original order (which is why he mentioned the incrementing numbers).

AFAIK It is kind of antipattern to use database table as a message queue

Can somebody explain to me why is it not a good idea to send msg inside a txn? if a msg was not transmitted then isnt it perfectly ok to rollback the transaction? Wont tailing the commit log of db get us the same behavior?

@xinwang8938

5 жыл бұрын

U mean "inside a local transaction"? We should avoid to do this like : Local Transaction => start Txn ==> send msg ==> waiting for response ( ALL reserved ressource for this transaction are suspended ) ===>OK => end Txn ===>KO => rollback

Interesting progression from "Monolith has this problem X" then "Microservices solved the issue X" but then we have problem Y and then "We solve problem Y by taking away some of the good parts of Microservices", which ends up in losing the benefits of both worlds of Monolith and Microservices.

For the last part, "Transactional messaging", why can't we utilize out of the box solutions like Kafka instead of using database commit log tailing?

@gygabytes

2 жыл бұрын

you could use the ack mechanism of kafka to only commit to the database when the message gets appended to the topic, but you will be coupling kafka (ie, kafka needs to be available) so that your system can function, which in theory it doesn't need it.. the event is for others, not for your system. so, if you use a local transaction log then your service will work as long as the database is available.. other component/service will send the messages/events to kafka

why not use an aggregate microservice for transactional operration?

40:50 ... Hmm... "assuming that the message broker has durable at-least-once delivery". Yes... assuming that. - and that it's up. I'm not sure I buy that async ReST doesn't work just because you can make the problem go away by introducing a magical component. If you have to run this yourself, is it easier to have high availability on the message-broker than on your service? why? ... and why can't the client just have retry logic a part of the saga state machine?

You could have a Saga Service that handles all sagas?

10:50 each services has its own databases. 12:30 how to maintain data consistency for each databases?

I am extremely confused by this orchestration based saga approach. Doesn't this present with the same problems that we set out to solve in the first place? For example, what if the saga has 5 steps and for some reason, after making the API call for the 3rd step (say to the CustomerService) and waiting for the API response, the orchestrator service goes down. How will the Saga Orchestrator after restarting know where to start from? It can at best start and try to perform 3rd step again but the 3rd step might have already been processed by CustomerService which means we might be trying to perform same action twice.

@JohnMcclaned

3 ай бұрын

The orchestrator is supposed to be durable and consistent. Meaning you could kill the orchestrator process and start it again and it should be able to load it's last committed state (from a database) and continue. You would use idempotent endpoints on each service the orchestrator calls to prevent double processing on the rare occasion.

The Saga seems to me like an AWS step Functions? Is that correct?

@kevinkkirimii

5 жыл бұрын

Yes

Started as a good talk, then slightly became messy after the 'theory of sagas' and when all problems were 'interesting' (but without solution), then, when it came to 'practical' part, everything turned into a complete mess with reinventing message brokers on top of specific features of databases. Anyway, we will probably get another 'open-source' framework :)

How we rollback if compensation transaction also fails

@AntonKa-yn4mb

5 жыл бұрын

And i have not heard how to solve the problem of transaction isoletion when we have concurrent transactions

@manikandanr3128

4 жыл бұрын

Compensation transactions should be idempotent and need to retry it unless its succeeded.

@sajhak

4 жыл бұрын

retry,, or simply ignore

@chang8106

4 жыл бұрын

Compensation transactions ， where in the monolithic approach a Orchestration Saga should aware of the failures when executing each entries, and execute compensate transactions if seeing failures in the steps.

Distributed monolith FTW...

how can I get that PPT ??

Choreography looks much better to me and more loosely coupled

Why not just have a separate "Transaction Service" that tracks the steps and whether they fail or not?

@deathmachine808

6 жыл бұрын

lol then it's surely just back to being a distributed transaction - it has a single co-ordinator?

@philadams9254

6 жыл бұрын

Hmm, yeah, maybe. Can't remember what I was thinking when I wrote that comment to be honest! 5 months in to using microservices and it's still hurting my brain!

@redsquarem3369

6 жыл бұрын

Thats essentially what it is, the saga/process manager governs n events from multiple services

I'm using gateway api as a middleman for my microservices

why are we trying to do this ? to make systems less complex , to have a smaller focused development teams ? to reduce time to production ? I feel we are making systems more complex , we are adding many more smaller databases , we are re-inventing the transaction mechanism such a waste of time , please do a video where you really need to have microservices and where not, its become a fashion to bounce the terms microservices , REST, K8S

@11:00 why would somebody make multiple databases for this? seems utterly crazy is this because one would naively be following the microservices dogma?

@tyrt400z

2 жыл бұрын

My reasoning would be the following: 1. The database will become very large very quickly, depending on the number of services. 2. Let's say you have some services that only run in certain situations, then you still have all their data cluttering up the database, even though they are not even being used at certain times. 3. Latency might occur if you have like 10-20 microservices all querying the same database at once. Furthermore, if your company becomes successful the code will keep growing (e.i. more services will be created) and at some point, the database will be a gigantic bottleneck of the whole system. There are more reasons, like the lack of data encapsulating you get when having just one big database. For instance, let's say you have many different organizations as costumers of your system, you might want to run different instances of microservice, each for each organization so it is separated. In the case of one big database (where you will lack separation) then you might end up in a situation where a developer writes code that fetches stuff from one organization but sends it to the wrong organization, which is no bueno.

Read more and get code samples at microservices.io/patterns/data/saga.html

Why not use TC/C ?

Had to set it to 1.5 speed make it more consumable

1.5 work for me .. :)

It's better to understand the current

Intro music name, plz ...

@alexanderbarvels7403

4 жыл бұрын

Daft Punk. Harder better faster stronger

At 8:37 , not monolith . It’s rather many monoliths

genius :-)

Everyone says this is a great talk. Honestly, I didn't see anything new. Little bits from this concept and that concept cobbled together. Talk is cheap. I want to see a working code.

@brite320

3 жыл бұрын

We all do. As a software engineer we need to understand the concept and create something unique. It is also perceived by the speaker that in the room, there are alot of engineer using different languages hence a working code is out of scope

Please don't roll your own workflow. See Durable Task Framework and Azure Durable Functions.

CreateOrderSaga? Really? Reinventing distributed transaction manager under a new name. The only difference is the sequential rollback invocation. Some silly stuff.

@roceb5009

6 жыл бұрын

And now when the Customer service changes how they do their credit check, now that's a code change for the order service. Hey, but we could fix that by putting all the code in the same repository, so the teams could change each other's code! This could really turn into a whole app architecture paradigm, I'll call it "macroservices"

@SvidetelKapitalizma

5 жыл бұрын

i hate whan on every case someone create new abstraction or even worse new framework, instead reuse existing one

@AntonKa-yn4mb

5 жыл бұрын

This agenda was about bla bla bla

@dmitribodiu1347

4 жыл бұрын

@@roceb5009 Nice catch! Using Saga as a central coordinator is a nightmare. It could be used inside bounded context, if some long running policy needed, but choreography is much preferred rather than have a central Saga place with Lots of dependencies...

Unfortunately the approach presented here is not perfect when comes to scalability: Order.state == PENDING is basically a database write lock in disguise.

(y) msilva

Will not work. The compensating transaction can fail also. In addition, when you commit (order created) then other processes can make decisions based on this fact. Those processes will perform some other business processes (transactions). Then , you decided to reverse order . But, the train left the station already. How will you rewind all other transactions?

talk starts at 15:16

If only there was some way for a database to expose a consistent interface layer while still allowing the "private data" (ie, actual tables) to be modified "under the covers". Oh wait, there is. Views. Stored procedures. Functions. You do not need an application level API layer to provide data model independence. Views/procs/functions *are an API layer*.

@benjaminrood1648

5 жыл бұрын

Indeed. _You'll have to take the objects from my cold, dead hands_

@fsociety2871

4 жыл бұрын

This is somewhat anti pattern because if you call views, sps or functions, your service is now coupled with those APIs sitting on the same database of another service.

@allmhuran

4 жыл бұрын

​@@fsociety2871 It's not an anti pattern, it's encapsulation 101. If you have a chain of "System A interacts with system B", it should do it through a public interface. If system B is a modern RDBMS then that interface can be made using views, procedures and functions. If you have a chain of "System C interacts with system B, and system B interacts with system A", then C is interacting with the stable API provided by B, and B is interacting with a stable API provided by A. Note that the actual technology implementation of each system is totally irrelevant. Any of A, or B, or C, might be a webAPI, or a database, or a file system, or a network. It doesn't matter. All that matters is that you don't interact directly to the internal, "private implementation" of that system. I think what you're describing is a situation where the system boundaries are not what I've described here. For example, we might say that "System A" is composed of *both* a database, *and* some kind of API layer. In this case, the database isn't a separate system, it's part of the implementation of system A. But again, the fact that the techology used for part of system A is "a database" is completely irrelevant to consumers. System A is already composed of lots of different elements (classes). Some of those classes expose public interfaces. Some of those interfaces are consumed by other systems. It could be that part of the public interface of system A happens to live in the database. To the caller it's totally irrelevant. As the designers of System A, we might decide to make the entire database private, and *only* have a public interface exposed at the dll layer, or webAPI layer. That's our call as the designers of System A. But no architectural principle is violated if we choose not to do that, as long as we are still encapsulating private data.

@fsociety2871

4 жыл бұрын

@@allmhuran But in the example you previously mentioned, a database object (view for example) to expose as an API let say of service A, if that will be used by service B which has it's own database then service B is now tightly coupled with service A's database.

@allmhuran

4 жыл бұрын

@@fsociety2871 If that's the definition of "tightly coupled", then anything which depends on anything is "tightly coupled". You're basically saying "If A calls B, then A is tightly coupled to B". It doesn't matter whether B is a database, a webAPI, a network, a file system, an input device, or anything else, because the underlying technology is not relevant in a discussion about coupling. I think you want to say that the database is "private implementation" simply by virtue of the fact that it is a database, and a webAPI is a public interface simply by virtue of the fact that it is a webAPI, but there's no logical reason why the particular technology choice is relevant to the discussion. They're all just systems, and they can all have public APIs. In this example, it sounds like you want to say that if service B interacts with an API provided by application A's serivce, then this is somehow "better" Than interacting with an API provided by application A's database. But why? If interacting with application A's database is bad, then interacting with its service is also bad, so interacting with it at all is bad.

MassTransit to the rescue 2021

This does mot work where ot maaters. It will eventially work where nobody cares.

pro tips 1.25x sounds normal.

10mins and still didn't found saga.

david blaine's father?

for peuple watching in 2023. don’t use saga! use a database that support multi/shard transaction!

Microservices isn't an architecture. Decoupling is. Microservices is nothing new. Decoupling has been around forever. (This is nothing related to the video, just felt like saying it.).

Precisely what stored procedures used to do so well with transactions wrapper. Anything that went wrong would rollback the whole thing. We keep reinventing the wheel with this kind of rubbish - “saga” a new word for same old solved problems

@morespinach9832

3 ай бұрын

At 24:00 the two “options” in Saga are both suboptimal 😅

So much repetition of the phrase "microservice architecture". Just say microservices! XD