How to Unlock the Power of Event-Driven Architecture | Designing Event-Driven Microservices
Vložit
- čas přidán 28. 06. 2024
- ► LEARN MORE: cnfl.io/microservices-101-mod...
An Event-Driven Architecture is more than just a set of microservices. Event Streams should represent the central nervous system, providing the bulk of communication between all components in the platform. Unfortunately, many projects stall long before they reach this point.
To learn more about Microservices, check out my Designing Event-Driven Microservices course on Confluent Developer: cnfl.io/microservices-101-mod...
Teams start by building an initial set of microservices but expanding beyond that to the rest of the system can be a real challenge. Transitioning from Event-Driven Microservices to an Event-Driven Architecture requires treating events like a product. However, the biggest challenge will be convincing the people around you that this is the right solution.
RELATED RESOURCES:
► Data as a Product: cnfl.io/3vnfg2S
► Implementing Streaming Data Products: cnfl.io/3TVeJi1
► 4 Key Types of Event-Driven Architecture: • 4 Key Types of Event-D...
► Microservices course playlist: bit.ly/designing-event-driven...
► Organizing for Enterprise Event Streaming: The New Central Nervous System of Business: cnfl.io/4aeWA4o
CHAPTERS:
00:00 - Intro
00:29 - What makes a data product successful?
01:08 - How can we meet the needs of the consumer?
01:43 - What makes an event easy to consume?
02:48 - How to ensure events are reliable.
03:32 - How to expand an event-driven system.
05:12 - How to sell your event-driven architecture to the rest of the team.
06:56 - Closing
--
ABOUT CONFLUENT
Confluent is pioneering a fundamentally new category of data infrastructure focused on data in motion. Confluent’s cloud-native offering is the foundational platform for data in motion - designed to be the intelligent connective tissue enabling real-time data, from multiple sources, to constantly stream across the organization. With Confluent, organizations can meet the new business imperative of delivering rich, digital front-end customer experiences and transitioning to sophisticated, real-time, software-driven backend operations. To learn more, please visit www.confluent.io.
#microservices #eventdrivenarchitecture #apachekafka #kafka #confluent - Věda a technologie
Wade here. I remember what this was like for me on an early project. We had to expand our Event Driven approach to a wider team. And we absolutely went about it the wrong way. We jumped in with a ton of enthusiasm, talking about all the ways that we were going to change things and how awesome it was going to be. And the people we needed to convince just shut down. They had no interest in what we wanted to hear. It wasn't until I became a consultant that I learned the error of my ways. You can't change the course of a ship instantly. It takes time. You have to build trust first. Once you have people's trust, they will be more open to new ideas. But if you try to throw new ideas at them without that trust, they are going to defend their territory. I blamed it on everyone else for not being open to new ideas. But the reality is that I was to blame for not being empathetic to their needs.
This quote really hit home : We can measure the success of our microservices, by the numbers of consumers that subscribe to its events. Just emiting events is not enough , having useful information to be shared and enriching it are indeed something we need to think about.
Wade here. I find this to be a common issue in software development. We celebrate too early. If we measure success by the number of events being emitted, that's too early. We should measure success by the number of events consumed. That makes more sense.
A colleague of mine once pointed this out in a different context. We often celebrate the launch of a new product or feature. But that's not really a success. The success comes when people consume that product or feature. That's what we should be celebrating.
Glad you enjoyed the video. And thanks for following up with a comment.
Thank you, that was a great journey through the topic and you were a really enjoyable host.
Wade here. Glad you enjoyed it. But hey, I've got good news, the journey isn't over. Keep an eye out because I should have a new video in a few weeks.
As usual, I really feel that you manage to put some structure and words on some of my practices.
Must see video.
Wade here. Glad you enjoyed the video. And I am glad you are following these practices.
Great video! One thing I'm struggling with a bit is in a case where one provides a public rest API with a synchronous calls, will that hide a event-driven architecture that's backing it, where one call to the API kicks off an event flow which has to complete the and terminate at a consumer to be returned by the original API request?
Wade here. There's different ways to do it, and it depends a lot on what your domain requirements are.
Generally, I would say consider separating your REST interface into READ (GET) and WRITE (POST, PUT, DELETE) calls.
Your WRITES can be done entirely asynchronously. I.E. When you do a POST, instead of getting back a 200 (OK), you get back a 202(Accepted). That 202 means that the command has been accepted for processing, but it may not be done yet. So it might take time. This is where your async architecture takes over.
When you do a READ (i.e. GET), here, you might rely more on synchronous calls because you are accepting an immediate and detailed response. And, odds are, your GET is going directly to the source of the data, so ideally, you won't have to talk to any other services and there shouldn't be a need for additional async messages.
The key is to avoid doing something like a POST that also returns the results of that POST because that's what forces you into a more synchronous design.
A well-designed REST interface can absolutely support asynchronous design.
OMG!! Great content writing !!
Wade here. I'm glad you enjoyed it. Hopefully you've checked out all of the videos in the series.