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.
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.
Wade here. Imagine your microservice is receiving "purchase" events. These events contain some basic details about a purchase, such as a date, an id, a payment method, etc. However, you want to enhance these events with additional information such as the customer name and address or maybe some product details. The microservice processing those purchase events can obtain this extra information, add it to the data from the original event, and then emit a new event that contains both the original data and the enhancements.
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.
OMG!! Great content writing !!
Wade here. I'm glad you enjoyed it. Hopefully you've checked out all of the videos in the series.
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.
Please explain how the event enrichments is happening in event driven microservices
Wade here. Imagine your microservice is receiving "purchase" events. These events contain some basic details about a purchase, such as a date, an id, a payment method, etc. However, you want to enhance these events with additional information such as the customer name and address or maybe some product details. The microservice processing those purchase events can obtain this extra information, add it to the data from the original event, and then emit a new event that contains both the original data and the enhancements.