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.
@FirojKhan-id4yx3 жыл бұрын
Th tty m .
@Gkay_Jr8 ай бұрын
yeah yeah 😁😍
@rajivbhatia11972 жыл бұрын
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.
@srikuhere3 жыл бұрын
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 .
@vivekjacob2320 Жыл бұрын
One of the better videos which gives a rationale for event driven architecture
@Pro_PlayerVedanth2 жыл бұрын
What an holistic explanation of the Architecture taking a practical problem situation ! Kudos.!
@johannisdihayco79782 жыл бұрын
Fantastic talk. A very clear discussion of event-driven micro services.
@osamaa.h.altameemi55924 жыл бұрын
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.
@javier.alvarez7643 жыл бұрын
what are they reinventing exactly?
@lifeisbeautiful20483 жыл бұрын
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.
@krumbergify3 жыл бұрын
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.
@monikakovacs60053 жыл бұрын
Whatever the presentation is, it's not decoupled microservices.
@srvmojo91904 жыл бұрын
this was a great presentation !! i wonder how the audience never had any question !!
@prab69584 жыл бұрын
This guy has a monotonic delivery style....they probably went to sleep
@frustin3 жыл бұрын
This is a really good explanation of event driven microservices/architecture
@stepseiventures25284 жыл бұрын
This was awesome and with the British accent, making it exciting. Nice presentation on EDA and microservices
@Bunfire1234 жыл бұрын
With the british accent 😂
@rimasg114 жыл бұрын
28:00 Well explained _Saga_ pattern
@Jam-ht2ky Жыл бұрын
beautifully done presentation and excellently presented great job
@shivchatur67034 жыл бұрын
nice one seen this just today. will discuss with my team, if this approach can be used in my current project. thanks Andrew.
@udarawijeratna0073 жыл бұрын
Thanks Team ! this is great video.
@BrendanPramjee Жыл бұрын
This was so well done !!!!!!
@nishikanttayade74464 жыл бұрын
Great presentation! Thanks
@crankerson3 жыл бұрын
Excellent presentation. Thank you
@vvijayar4 жыл бұрын
great presentation , Thank You!
@amitbaijal421 Жыл бұрын
Great Presentation
@willl00142 жыл бұрын
I think micro services is really hard to get right, but if you do the benefits are substantial
@RodyDavis3 жыл бұрын
This was incredible, I know understand pub/sub
@nasserabbassi73034 жыл бұрын
just by the way the mentioned link by Andrew on IBM website is not available
@kleberpovoacao Жыл бұрын
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.
@directorans3 жыл бұрын
Really good talk!
@nicole-annmenezes55653 жыл бұрын
Thanks! It was is very helpful
@kevinkkirimii3 жыл бұрын
Is there any event driven video without kafka ?
@hhamedi683 жыл бұрын
It was great thank you
@nasamind Жыл бұрын
Awesome
@digisecureagent76793 жыл бұрын
do we need to have event sourcing. + saga at the same time to achieve consistency or event sourcing alone is enough?
@sorteslyngel2k2 жыл бұрын
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.
@zahirjacobs7164 жыл бұрын
Great presentation!
@1testrad3 жыл бұрын
thanks ...
@mandarin85134 жыл бұрын
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.
@joek45633 жыл бұрын
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..
@mandarin85133 жыл бұрын
@@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.
@TrulyLordOfNothing2 жыл бұрын
@@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?
@mandarin85132 жыл бұрын
@@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.
@chessmaster856 Жыл бұрын
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
@staatsfernsehen44452 жыл бұрын
Good presentation but the arguments against Microservices sharing a database don't hold: database != schema
@monikakovacs60053 жыл бұрын
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?
@stefanogrillo60402 жыл бұрын
And this is stewie griffin from the future😄
@80-two Жыл бұрын
"Kind of" ?
@panprasanta Жыл бұрын
Making things much more complicated without a clear benifits। "This new way of doing things" will make developers life horrible!