Hi Mark, I just saw this video. Although all is correct in this video, what is missing is to compare REST/synchronized communication with event-driven. When to use EDA and when REST? What type of combination is the best. As you said trade off is always there. I would say that REST is better for Micro services when 1 monolith app is broken up into several MS apps that still logically work on the same task but as a separate services and require data in a real-time with zero latency. Once they complete that work and they need to call and pass the information to the next micro-service (MS) that belongs to another logical group, they can use JMS and decoupled asynchronous communication. So services that use to be part of same monolith can keep synchronous communication between each other, while communicating with other services they use messaging. My take on this topic. As you said everything is trade off. Greetings from Switzerland.
@@markrichards5014 no worries! Even after 36 years in IT with infrastructure, data and voice com, development and architecture, I still find plenty to learn from your series. Well done sir!
Can you do a video for all developers who has 10 years and more work experience and want to become Architect. How to sell yourself in the interview etc?
But man... how joyfull is to work with these kind of systems. I would also add a pretty complex tooling and the automation requirement as a downside. The investment just to set the development workflow is pretty high. I like to make the analogy with building your own workshop by hand. You shape the slabs, stick them together, etc, eventually you start to bring in your tools, you get familiar with those tools, develop the efficient workflow... and only then you see the dividends. Same with EDA. Just to build that workshop is pretty expensive, but once that is done... its pleasure to work with it. You can itterate over new ideas so quickly. You can shape the existing data in any new product you want just by replaying the topics. Etc.
Hi Mark, Nice video. I would say that error handling and workflow become interesting instead of complicated. One has to implement Choreography or Orchestration based SAGA patterns to handle them. Vikas
Thanks for this wonderful video, Mark ! However, I disagree that "contract coupling" is a disadvantage for EDA. Inter services communication (this includes async. as well) is largely possible due to the Consumer and Provider agreeing to a pre-defined contract. It can be more disadvantageous to EDA than it would for microservices or any API based integration. Thoughts ?
Async adds an additional dimension to contract coupling in that with async communications, particularly pub/sub with topics, you may not know who is responding to your event. This makes it a little bit harder than other architecture styles (like microservices or service-based) to agree on contracts and change them.
I am reading yr book. It's excellent. I hope you still have the strength to write another one after 5 years (assumed lifespan of an architecture textbook).
I bet many developers can rely to experience, when they tried to use events in their code to build logic and quickly realize the complexity it immediately creates. Even your own code with known scenarios quickly became unsupportable, error handling and debugging tools does not perform as good, then try to multiple this for real world cases, when requirements need to be clarified, politics during decision making withing your own team and external teams.
Is there any way to overcome disadvantage that will help alot For event timing ? - maybe sending on same partiotion using common partition key But that's not scalable in a sense then Need help on this, please
Unfortunately there is no easy, generic solution for controlling the timing of parallel events. Some techniques I've used include mediators (orchestrators) that either poll or receive an ACK when the event is processed to know to release an event, or data polling to determine event state. The details of these solutions are too complex for a comment reply, so I will think about doing these solutions in a future lesson in Software Architecture Monday.
@@markrichards5014 Thanks for the reply Yeah sure, that will be helpful if you can suggest about how to overcome disadvantages, with maybe tradeoff of solutions in one of monday video Actually, was facing issues, when two orderPlaced are on 2 partitions (as using Kafka along with BPMN) and event processing sequence matters And if one partition is slow, I get issue of latter one being processed first (which was submitted late) To solve this one solution we discussed was to have orders for a product placed on same partition To keep it in sequence in terms of consumption in sequence But that restricts all product orders on single partition and decreases throughput
Change management, versioning also gets much more complex. Next versions of code will need to consume all versions of events. It means that bug fix is way more expensive than adding a new feature, especially it it was producing "buggy" events. Eventually if is only good for event log processing - where consistency is in low value.
![Summer Walker - Heart Of A Woman [Official Lyric Video]](http://i.ytimg.com/vi/SFddctbZzw8/mqdefault.jpg)
Another excellent lesson from a very knowledgeable and pragmatic professional. Thanks!
Hi Mark, I just saw this video. Although all is correct in this video, what is missing is to compare REST/synchronized communication with event-driven. When to use EDA and when REST? What type of combination is the best. As you said trade off is always there. I would say that REST is better for Micro services when 1 monolith app is broken up into several MS apps that still logically work on the same task but as a separate services and require data in a real-time with zero latency. Once they complete that work and they need to call and pass the information to the next micro-service (MS) that belongs to another logical group, they can use JMS and decoupled asynchronous communication. So services that use to be part of same monolith can keep synchronous communication between each other, while communicating with other services they use messaging. My take on this topic. As you said everything is trade off.
Greetings from Switzerland.
Really liked your review of pros and cons! Thank you!
Love your videos, they’re helping me a lot with architecture knowledge! Thanks 🙏
Glad you like them!
I just love the way you talk 😀
Hey mark, your videos are awesome 👍
Love your videos! As an aside, you may want to isolate table vibration from your mic - my subwoofer makes your hand rests very dramatic events 😀
Thanks for the tip! I shall pay close attention to that in future videos.
@@markrichards5014 no worries! Even after 36 years in IT with infrastructure, data and voice com, development and architecture, I still find plenty to learn from your series. Well done sir!
😆 now I understand what it was. I was listening to this video in the headphones.
Can you do a video for all developers who has 10 years and more work experience and want to become Architect. How to sell yourself in the interview etc?
Nice explanation friend. Have seen your channel, and its very organized and well explained. Suscribed. Saludos. 🤙
But man... how joyfull is to work with these kind of systems. I would also add a pretty complex tooling and the automation requirement as a downside. The investment just to set the development workflow is pretty high. I like to make the analogy with building your own workshop by hand. You shape the slabs, stick them together, etc, eventually you start to bring in your tools, you get familiar with those tools, develop the efficient workflow... and only then you see the dividends. Same with EDA. Just to build that workshop is pretty expensive, but once that is done... its pleasure to work with it. You can itterate over new ideas so quickly. You can shape the existing data in any new product you want just by replaying the topics. Etc.
Hi Mark,
Nice video.
I would say that error handling and workflow become interesting instead of complicated.
One has to implement Choreography or Orchestration based SAGA patterns to handle them.
Vikas
Excellent explanation. Can you please do video on milt-experience/omnichannel?
Thanks for this wonderful video, Mark ! However, I disagree that "contract coupling" is a disadvantage for EDA. Inter services communication (this includes async. as well) is largely possible due to the Consumer and Provider agreeing to a pre-defined contract. It can be more disadvantageous to EDA than it would for microservices or any API based integration. Thoughts ?
Async adds an additional dimension to contract coupling in that with async communications, particularly pub/sub with topics, you may not know who is responding to your event. This makes it a little bit harder than other architecture styles (like microservices or service-based) to agree on contracts and change them.
@mark what would be the best strategy to change the contract when needed? Can backward compatibility be maintained?
One of the challenges is contract changes, your consumers have to compatible with different version of contracts for sometime.
I am reading yr book. It's excellent. I hope you still have the strength to write another one after 5 years (assumed lifespan of an architecture textbook).
As a matter of fact just finishing up our second book called "Software Architecture: The Hard Parts" which will be coming out in late Autumn
@@markrichards5014 I'll keep an eye out for that. though I am sure you are going to mention it. Did you collaborate with someone or is it just you?
I bet many developers can rely to experience, when they tried to use events in their code to build logic and quickly realize the complexity it immediately creates. Even your own code with known scenarios quickly became unsupportable, error handling and debugging tools does not perform as good, then try to multiple this for real world cases, when requirements need to be clarified, politics during decision making withing your own team and external teams.
Is there any way to overcome disadvantage that will help alot
For event timing ? - maybe sending on same partiotion using common partition key
But that's not scalable in a sense then
Need help on this, please
Unfortunately there is no easy, generic solution for controlling the timing of parallel events. Some techniques I've used include mediators (orchestrators) that either poll or receive an ACK when the event is processed to know to release an event, or data polling to determine event state. The details of these solutions are too complex for a comment reply, so I will think about doing these solutions in a future lesson in Software Architecture Monday.
@@markrichards5014 Thanks for the reply
Yeah sure, that will be helpful if you can suggest about how to overcome disadvantages, with maybe tradeoff of solutions in one of monday video
Actually, was facing issues, when two orderPlaced are on 2 partitions (as using Kafka along with BPMN) and event processing sequence matters
And if one partition is slow, I get issue of latter one being processed first (which was submitted late)
To solve this one solution we discussed was to have orders for a product placed on same partition
To keep it in sequence in terms of consumption in sequence
But that restricts all product orders on single partition and decreases throughput
Change management, versioning also gets much more complex.
Next versions of code will need to consume all versions of events.
It means that bug fix is way more expensive than adding a new feature, especially it it was producing "buggy" events.
Eventually if is only good for event log processing - where consistency is in low value.