Creating event-driven microservices: the why, how and what by Andrew Schofield

Please subscribe to our KZbin channel @ bit.ly/devoxx-youtube
Like us on Facebook @ / devoxxcom
Follow us on Twitter @ / devoxx
Any team that has made the jump from building monoliths to building microservices knows the complexities you must overcome to build a system that is functional and maintainable. Building a microservice architecture that is low latency and only communicates using REST APIs is even more tricky, with high latency for requests being a common concern. This talk will explain how you can use events as the backbone of your microservice architecture and build an efficient, event-driven system. It will cover how to get started with designing your microservice architecture and the key requirements any system needs to fulfil. It will also introduce the different patterns you will encounter in event-driven architectures and the advantages and disadvantages of these choices. Finally it will explain why Apache Kafka is a great choice for event-driven microservices.

[@srikuhere]

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 .

[@assembledstardust]

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-id4yx]

Th tty m .

[@gabrielkamau-mi3sz]

yeah yeah 😁😍

[@rajivbhatia1197]

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.

[@Pro_PlayerVedanth]

What an holistic explanation of the Architecture taking a practical problem situation ! Kudos.!

[@frustin]

This is a really good explanation of event driven microservices/architecture

[@johannisdihayco7978]

Fantastic talk. A very clear discussion of event-driven micro services.

[@shivchatur6703]

nice one seen this just today. will discuss with my team, if this approach can be used in my current project. thanks Andrew.

[@vvijayar]

great presentation , Thank You!

[@vivekjacob2320]

One of the better videos which gives a rationale for event driven architecture

[@lifeisbeautiful2048]

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.

[@Jam-ht2ky]

beautifully done presentation and excellently presented great job

[@crankerson]

Excellent presentation. Thank you

[@rimasg11]

28:00 Well explained _Saga_ pattern

[@nishikanttayade7446]

Great presentation! Thanks

[@udarawijeratna007]

Thanks Team ! this is great video.

[@BrendanPramjee]

This was so well done !!!!!!

[@opelfahrer91]

Great talk, thanks for sharing

[@nicole-annmenezes5565]

Thanks! It was is very helpful

[@directorans]

Really good talk!

[@amitbaijal421]

Great Presentation

[@srvmojo9190]

this was a great presentation !! i wonder how the audience never had any question !!

[@prab6958]

This guy has a monotonic delivery style....they probably went to sleep

[@krumbergify]

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.

[@monikakovacs6005]

Whatever the presentation is, it's not decoupled microservices.

[@stepseiventures2528]

This was awesome and with the British accent, making it exciting. Nice presentation on EDA and microservices

[@Bunfire123]

With the british accent 😂

[@nasserabbassi7303]

just by the way the mentioned link by Andrew on IBM website is not available

[@osamaa.h.altameemi5592]

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.alvarez764]

what are they reinventing exactly?

[@RodyDavis]

This was incredible, I know understand pub/sub

[@hhamedi68]

It was great thank you

[@zahirjacobs716]

Great presentation!

[@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.

[@kevinkkirimii]

Is there any event driven video without kafka ?

[@nasamind]

Awesome

[@1testrad]

thanks ...

[@digisecureagent7679]

do we need to have event sourcing. + saga at the same time to achieve consistency or event sourcing alone is enough?

[@sorteslyngel2k]

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.

[@willl0014]

I think micro services is really hard to get right, but if you do the benefits are substantial

[@mohammedalzamil7191]

epic

[@PranaySoniKumar]

6:00

[@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

[@stefanogrillo6040]

And this is stewie griffin from the future😄

[@f135ta]

"Kind of" ?

[@staatsfernsehen4445]

Good presentation but the arguments against Microservices sharing a database don't hold: database != schema

[@cinderellarouge]

FOf understanding that I got 4 years

[@pm71241]

Hmm... a lot of hand waving wrt. the consistency.

[@mandarin8513]

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.

[@joek4563]

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..

[@mandarin8513]

@@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.

[@TrulyLordOfNothing]

@@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?

[@mandarin8513]

@@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.

[@monikakovacs6005]

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?

[@panprasanta]

Making things much more complicated without a clear benifits। "This new way of doing things" will make developers life horrible!

[@angstrom1058]

NO. Don't do it this way :o OMG