Definitely one of the better high level overview presentations I've seen on these subject matters. Conceptually I was already familiar with the architecture and I have even put some into practice by rolling our own custom Event Store based on the Event Sourcing architectural pattern (though I admit, probably very poorly) but the speaker has done a great job of combining all of the knowledge and approaches that are our there. Best 40 minutes I've spend on deepening my knowledge and understanding in this area. Thanks for the upload.
Most definitely one of the most complete walkthrough of SAGA implementation using event sourcing (and orchestration). Excellent job on combining approaches, patterns, and examples out there.
brilliant talk , how all the concepts around micro services and event driven arch came together was like an art masterpiece . thank you for posting this talk . Appreciate it .
A common argument for microservices is that it leads to decoupling between parts and less ”spagetti”. However I fear that overusing publish/subscribe yields the same kind of spagetti, just over a network instead of between functions and classes.
At CQRS slide (36:24 minute) why not use some replication feature from database instead of event backbone ? Not clear for me the benefit using event backbone on this case.
That was really slick. Thx a ton. I am shocked by the existing gap between what the industry has and what most of people in Academia are trying to re-invent. IoT Researchers should have the topics in this talk as their starting point and improve up-on. Not re-invent the same wheel 1000 times.
Good one, indeed. Inclusion of real production problem solution using patterns like Not only DB, Sagas, Event sourcing helps to understand real-life problem along with the solution.
They do not solve the same problem. Event sourcing can give eventually consistency with auditable events while the saga pattern tries to solve the issue of having distributed transactions.
Show some code. Everything looks good at high level. Someone will do something and everything is good like drawing a car on paper and say that everything runs with no problem. That is not enough
There's alot I don't agree with. Purely from a user experience point of view. Why would you pay for something then get a push notification that it was successful? You are sacrificing HCI concepts for? Request response matches how humans interface with software. You click on something then it tells you what happened.
Doesn't have to be a push notification for it to be asynchronous. You could have the same event driven architecture he describes but the user gets the update by polling from the front-end like most reactive web apps. The example he gave doesn't have to change user experience. You typically get quick response times when you interact with sites like youtube and instagram yet they are using this event driven architecture in the backend..
@@joek4563 Don't get me wrong. I am not talking about all of EDA. I use EDA in our systems at work but when it comes to HCI we fake responses and use a concept of eventual consistency. We work with a philosophy that is to tell the user immediately if something "should" succeed. The user can go about their business while the EDA is still processing the payment or what not. Only in extreme cases such as system failures will there be a chance of the event not being processed. I am talking specifically about his example, I don't agree with using push notifications to tell the user if something is complete. Push notifications are reserved for notifying the user about something that was not initiated but the current user but rather some external source.
@@mandarin8513 I am intrigued, Mitch. We use Push Notif. for notifying the user about a call or that a doctor is available. In what context do you think PN are not good, why? and if you wouldn't use it in this case, what would you rather use to let the user know his payment is successful?
@@TrulyLordOfNothing I'm not saying that PNs are not good. They are just not good in this context. For example you said to know when doctors are available or when you receive a phone call. Both of those events are initiated by an external source and not by you. This is a perfect case for PN. When you initiate the event such as paying for something, then why should a user wait for a PN just because you are using event based architecture. It means you sacrifice UX for the sake of simple backend architecture when there are more complex solutions such as eventual consistency and saga patterns. You can tell the user immediate the payment is successful on the response of the users request.
This is some "straight jacket over Kafka" presentation. I think there is a lot of confusion in it over terms, the definitions are not specific enough, there is a bit of hand waving. I'm not sure the presenter knows what write algorithms look like and what happens in the event of failure. The pros and cons are not explained. Pipes should be dumb and services smart. Where is DDD?
Definitely one of the better high level overview presentations I've seen on these subject matters. Conceptually I was already familiar with the architecture and I have even put some into practice by rolling our own custom Event Store based on the Event Sourcing architectural pattern (though I admit, probably very poorly) but the speaker has done a great job of combining all of the knowledge and approaches that are our there. Best 40 minutes I've spend on deepening my knowledge and understanding in this area.
Thanks for the upload.
Th tty m
.
yeah yeah
😁😍
Most definitely one of the most complete walkthrough of SAGA implementation using event sourcing (and orchestration). Excellent job on combining approaches, patterns, and examples out there.
Fantastic talk. A very clear discussion of event-driven micro services.
brilliant talk , how all the concepts around micro services and event driven arch came together was like an art masterpiece . thank you for posting this talk . Appreciate it .
What an holistic explanation of the Architecture taking a practical problem situation ! Kudos.!
One of the better videos which gives a rationale for event driven architecture
A common argument for microservices is that it leads to decoupling between parts and less ”spagetti”. However I fear that overusing publish/subscribe yields the same kind of spagetti, just over a network instead of between functions and classes.
Whatever the presentation is, it's not decoupled microservices.
At CQRS slide (36:24 minute) why not use some replication feature from database instead of event backbone ? Not clear for me the benefit using event backbone on this case.
beautifully done presentation and excellently presented great job
This is a really good explanation of event driven microservices/architecture
That was really slick. Thx a ton. I am shocked by the existing gap between what the industry has and what most of people in Academia are trying to re-invent. IoT Researchers should have the topics in this talk as their starting point and improve up-on. Not re-invent the same wheel 1000 times.
what are they reinventing exactly?
28:00 Well explained _Saga_ pattern
Good one, indeed. Inclusion of real production problem solution using patterns like Not only DB, Sagas, Event sourcing helps to understand real-life problem along with the solution.
This was awesome and with the British accent, making it exciting. Nice presentation on EDA and microservices
With the british accent 😂
this was a great presentation !! i wonder how the audience never had any question !!
This guy has a monotonic delivery style....they probably went to sleep
just by the way the mentioned link by Andrew on IBM website is not available
Is there any event driven video without kafka ?
This was so well done !!!!!!
Great Presentation
nice one seen this just today.
will discuss with my team, if this approach can be used in my current project.
thanks Andrew.
Thanks Team ! this is great video.
Great presentation! Thanks
Excellent presentation. Thank you
great presentation , Thank You!
do we need to have event sourcing. + saga at the same time to achieve consistency or event sourcing alone is enough?
They do not solve the same problem. Event sourcing can give eventually consistency with auditable events while the saga pattern tries to solve the issue of having distributed transactions.
This was incredible, I know understand pub/sub
Really good talk!
Thanks! It was is very helpful
I think micro services is really hard to get right, but if you do the benefits are substantial
Awesome
It was great thank you
thanks ...
Great presentation!
6:00
"Kind of" ?
Show some code. Everything looks good at high level. Someone will do something and everything is good like drawing a car on paper and say that everything runs with no problem. That is not enough
Good presentation but the arguments against Microservices sharing a database don't hold: database != schema
There's alot I don't agree with. Purely from a user experience point of view. Why would you pay for something then get a push notification that it was successful? You are sacrificing HCI concepts for? Request response matches how humans interface with software. You click on something then it tells you what happened.
Doesn't have to be a push notification for it to be asynchronous. You could have the same event driven architecture he describes but the user gets the update by polling from the front-end like most reactive web apps. The example he gave doesn't have to change user experience. You typically get quick response times when you interact with sites like youtube and instagram yet they are using this event driven architecture in the backend..
@@joek4563 Don't get me wrong. I am not talking about all of EDA. I use EDA in our systems at work but when it comes to HCI we fake responses and use a concept of eventual consistency. We work with a philosophy that is to tell the user immediately if something "should" succeed. The user can go about their business while the EDA is still processing the payment or what not. Only in extreme cases such as system failures will there be a chance of the event not being processed. I am talking specifically about his example, I don't agree with using push notifications to tell the user if something is complete. Push notifications are reserved for notifying the user about something that was not initiated but the current user but rather some external source.
@@mandarin8513 I am intrigued, Mitch. We use Push Notif. for notifying the user about a call or that a doctor is available. In what context do you think PN are not good, why? and if you wouldn't use it in this case, what would you rather use to let the user know his payment is successful?
@@TrulyLordOfNothing I'm not saying that PNs are not good. They are just not good in this context. For example you said to know when doctors are available or when you receive a phone call. Both of those events are initiated by an external source and not by you. This is a perfect case for PN. When you initiate the event such as paying for something, then why should a user wait for a PN just because you are using event based architecture. It means you sacrifice UX for the sake of simple backend architecture when there are more complex solutions such as eventual consistency and saga patterns. You can tell the user immediate the payment is successful on the response of the users request.
And this is stewie griffin from the future😄
This is some "straight jacket over Kafka" presentation. I think there is a lot of confusion in it over terms, the definitions are not specific enough, there is a bit of hand waving. I'm not sure the presenter knows what write algorithms look like and what happens in the event of failure. The pros and cons are not explained. Pipes should be dumb and services smart. Where is DDD?
Hmm... a lot of hand waving wrt. the consistency.
FOf understanding that I got 4 years
epic
Making things much more complicated without a clear benifits। "This new way of doing things" will make developers life horrible!
NO. Don't do it this way :o OMG
Great talk, thanks for sharing