Great talk. But one important point that almost all speakers skip is that implementing your use case in an event driven model forces you to change your user interaction flow. It is not all or none anymore. I found it hard to convince my business to reimagine the UI model than to implement this architecture
Great point that needs to be talked about more often. Event sourced arch has to be agreed upon and somewhat understood from both business and tech for it to work effectively.
Seeing this pattern so many times - microservices and event-driven have values but overemphasising the goods and dumping traditional design around apis and db, the system "may" end up with much worse things - event schema vs. normalized db schema, bloated message vs. concise api, building on top of every single piece of event vs. building on top existing modules and functional apis, etc.
Love the talk - for all those thinking of going from Synchronous to Asynchronous event-based communication just remember - nothing creates flaky tests like asynchronous communication (at scale anyways!).
About the event driven part of the presentation: What doesn't get addressed in the talk is that we are changing one dependency that I wrote, I control and (more importantly) I understand, for a complex middleman on which both services depend now. The speaker seems to assume that my service can be down but Kafka can't. And she also assumes that if Kafka has a problem I know how to fix it. It's an approach with many advantages, but none for free.
Very informative with clear illustrations. Probably the best content I have seen so far on Microservices, covering the latest trends and direction in the field. Thank you very much ! Would also be really interested in an online course if you could offer, apart from the book publications :-)
Brilliant stuff - many thanks. Within the Microservices playlist on this channel, I posted on a video a month back this because it seems they were trying to use analysis tools to try and repair "chattiness" : ua-cam.com/video/0G5O1ffYIPI/v-deo.html - I wrote this - "have unease about the microservices presented for Graph analysis - why didn't they just be designed as Asynchronous from the outset using things like Kafka - not really sure about this one. Why would you need in retrospect to model your system to try and retrofit it to become more asynchronous - why not design it from the outset with an event bus and be as asynchronous as possible which many other GOTO videos gave emphasised. Asynchronous is surely as close as we have to a sliver bullet for scalability and teams being able to work independently on their microservices. Cheers, K" With your video I have some more thoughts on the subject. It seems the Netflix glamorous example did not feature a Kafka bus - it seemed really glamorous and complex on its visualisations and I think it has become a kind of glamourous "example trap" - where there is NO BUS. Is this not the case? Without a bus as you say the whole notion of "Independence" is really lost. Further, I would say there are a couple of other major concerns aside from "Independence" - that of "Prophylaxis" and that of "Not following Glamourous examples without question like Netflix just because there is some code to re-use". "Prophylaxis" is very useful in terms of not trying to repair broken API systems which don't have a bus (trying to tackle symptoms after the fact) - but rather try and get stuff right in design and part of that is to make sure that the examples followed ARE NOT NETFLIX which seems glamorous, complex but does not seem to be that practical for most organisations. With your presentation here, I think there are less excuses for organisations to design their microservices badly because you have given a great tour of the up and downsides of different approaches and also tackled a question not tackled by many - the potential adding of a candidate new service and what issues that creates. So CONGRATS. Cheers, K
OMG, cannot believe you watch software developing content. I used to watch your chess channel when I was in university studying computer science. How time flies... 😥
Good talk, I am designing exactly this sort of system. There are a couple of topics that come out of this idea that are quite complex in terms of implementation details that this talk didn't go into. I'll only mention one here, which is when events have an ordering dependency. For example, suppose we have a typical system that has order headers, each of which can have one or more ordered items. These are separate entities in the model, and thus have their own event. On system A I create an order, and THEN I can add ordered items to that order header. These are separate schemas in the event model. They will be published independently. But that also means they will be consumed independently. So, we have a problem. We have separate topics in the event broker - one topic for orders, one topic for order lines. They have to be separate topics, otherwise there is no structure to the schema, and there's no way for consumers to subscribe to only the topics they care about. Imagine they weren't separate topics, and I said "we publish everything to a single queue of events, and each event could be any type", and then each subscriber has their copy of that queue, then every subscriber has to process every event in order to decide which events it wants, and which events it can ignore. That's bad - every system is now trying to process all events from every other system, even if that just means "so it knows that it can ignore it". S, we stick with separate topics. But now we can't control the order in which subscribers process those events. If some system is subscribed to both orders and order lines, and it happens to process the message in its order lines queue before it processes the message in the orders queue, then it may not be able to ingest the line message - for example, if it is using a relational database, it would get a foreign key violation. You might say "well it can just insert a default order header when it receives the line, and then update the order header when it gets the real order header". But it's not always obvious what those default header details should be, and if you're working with some vendor system, you might not even be able to support that behaviour. Another approach is to say "that's ok, the order detail will fail to be ingested on the first attempt, but we know it will retry. Eventually the order header will arrive, and after it does the retry on the line will succeed". This does work in principle most of the time, but it's a bit wasteful. And there are some occasions when it won't work. For example, let's say I create the order, then create the order line, then delete the order line, and then delete the order. All of this happens in system A. System B will receive 2 messages each on 2 queues. Let's say it processes the order header queue first. It will create the order, and then delete it. Then it will receive a message to create the order line, but it will never be able to ingest that message, because it has already received the order deletion event. So system B is now blocked on the order line processing queue until the retry decay eventually gives up entirely, which could mean that its order line queue is blocked for a long time. And it can't simply step over that line level event and process the next one instead, because on any single topic events *must* be processed in order. OK, so a single topic which contains all events across all schemas has big issues with data volumes (because the entire queue of events is replicated for every subscriber) and impacts on subscriber performance (because every subscriber has to process that entire queue), but separate topics which provide simpler schema validation and does not require subscribers to process every single event might create logical problems with ordering. I am not aware of any "theoretically sound" solution to this problem. There are other problems as well, which have similar implementation headaches. That's just one of the difficult implementation details that I struggle with. I still think that this approach to shared state is definitely the right way to build a distributed system. I just don't think anyone has come up with a completely satisfactory solution to implementation details like this one.
Well actually, I am aware of one "theoretically sound" solution to this problem - because I built it as a proof of concept. But as far as I know the idea is not "natively" supported in any event brokers. The idea was to have a "control" queue for each subscriber, where every element in the queue is a pointer to some other queue that contains the next message in order. But that has its own implementation difficulties. When I built it, I built it entirely using SQL - because it was just a proof of concept. It used tables as queues, and made use of sql server service broker for transactional decoupling. And it works, at least in principle. But I have no idea whether it can be written in a way that scales, it was just a theoretical proof and was never subject to a real production workload, and it does require some fancy logic in the messaging side.
Messages with ordering dependencies have to be in the same queue. You could have a message like "Order Update" that can have subtypes of "Order Create" or "Add line item".
@@jnnnnn The ordering dependencies here come from what are essentially foreign key relationships in the source system. In a well designed relational database, those declarative constraints tend to chain quote deep: invoice lines depend upon order lines, order lines depend upon orders, orders depend upon products and customers, and so on and so on. You can't put all of that into the same queue.
It would be good if you rename the video to "Microservices: Event driven architecture". This current title is very misleading. I thought I might learn something new, I already knew about event-driven systems.
You can watch "Monolith Decomposition Patterns" GOTO 2019 talk from Sam Newman" who was writter a pair of books about Microservices. ua-cam.com/video/9I9GdSQ1bbM/v-deo.html P.S. Microservices were suppoused to have it's own database so that they can be deployed independently but the migration to this ideal architecture state is complex. If not some parts of the database can become part of the contract.
@@caneminops2595 I think they're saying that this video should have had proper subtitles written by a human. It's a valid point about accessibility IMHO.
the service mesh and api gateway part was awesome and clear concise
Great talk. But one important point that almost all speakers skip is that implementing your use case in an event driven model forces you to change your user interaction flow. It is not all or none anymore. I found it hard to convince my business to reimagine the UI model than to implement this architecture
Great point that needs to be talked about more often. Event sourced arch has to be agreed upon and somewhat understood from both business and tech for it to work effectively.
Extremely useful - thanks - just wish you had more time to expand on some of these topics
Yeah I wanna do that because me also loved of microservices ...❤️❤️👍🏻
Seeing this pattern so many times - microservices and event-driven have values but overemphasising the goods and dumping traditional design around apis and db, the system "may" end up with much worse things - event schema vs. normalized db schema, bloated message vs. concise api, building on top of every single piece of event vs. building on top existing modules and functional apis, etc.
Really great talk, thankyou for your valuable time and efforts.
Love the talk - for all those thinking of going from Synchronous to Asynchronous event-based communication just remember - nothing creates flaky tests like asynchronous communication (at scale anyways!).
About the event driven part of the presentation: What doesn't get addressed in the talk is that we are changing one dependency that I wrote, I control and (more importantly) I understand, for a complex middleman on which both services depend now. The speaker seems to assume that my service can be down but Kafka can't. And she also assumes that if Kafka has a problem I know how to fix it.
It's an approach with many advantages, but none for free.
Great video!
So in 21 century we can have architecture without gateway?
Very informative with clear illustrations. Probably the best content I have seen so far on Microservices, covering the latest trends and direction in the field. Thank you very much ! Would also be really interested in an online course if you could offer, apart from the book publications :-)
REST does not have to be HTTP + JSON, you can also use TCP + CSV if you really really want :D
What problem would that solve? Certainly nothing relevent to this talk.
Brilliant stuff - many thanks. Within the Microservices playlist on this channel, I posted on a video a month back this because it seems they were trying to use analysis tools to try and repair "chattiness" : ua-cam.com/video/0G5O1ffYIPI/v-deo.html - I wrote this - "have unease about the microservices presented for Graph analysis - why didn't they just be designed as Asynchronous from the outset using things like Kafka - not really sure about this one. Why would you need in retrospect to model your system to try and retrofit it to become more asynchronous - why not design it from the outset with an event bus and be as asynchronous as possible which many other GOTO videos gave emphasised. Asynchronous is surely as close as we have to a sliver bullet for scalability and teams being able to work independently on their microservices. Cheers, K"
With your video I have some more thoughts on the subject. It seems the Netflix glamorous example did not feature a Kafka bus - it seemed really glamorous and complex on its visualisations and I think it has become a kind of glamourous "example trap" - where there is NO BUS. Is this not the case? Without a bus as you say the whole notion of "Independence" is really lost. Further, I would say there are a couple of other major concerns aside from "Independence" - that of "Prophylaxis" and that of "Not following Glamourous examples without question like Netflix just because there is some code to re-use". "Prophylaxis" is very useful in terms of not trying to repair broken API systems which don't have a bus (trying to tackle symptoms after the fact) - but rather try and get stuff right in design and part of that is to make sure that the examples followed ARE NOT NETFLIX which seems glamorous, complex but does not seem to be that practical for most organisations.
With your presentation here, I think there are less excuses for organisations to design their microservices badly because you have given a great tour of the up and downsides of different approaches and also tackled a question not tackled by many - the potential adding of a candidate new service and what issues that creates. So CONGRATS. Cheers, K
OMG, cannot believe you watch software developing content. I used to watch your chess channel when I was in university studying computer science.
How time flies... 😥
Good talk, I am designing exactly this sort of system.
There are a couple of topics that come out of this idea that are quite complex in terms of implementation details that this talk didn't go into. I'll only mention one here, which is when events have an ordering dependency.
For example, suppose we have a typical system that has order headers, each of which can have one or more ordered items. These are separate entities in the model, and thus have their own event. On system A I create an order, and THEN I can add ordered items to that order header. These are separate schemas in the event model. They will be published independently.
But that also means they will be consumed independently.
So, we have a problem. We have separate topics in the event broker - one topic for orders, one topic for order lines. They have to be separate topics, otherwise there is no structure to the schema, and there's no way for consumers to subscribe to only the topics they care about. Imagine they weren't separate topics, and I said "we publish everything to a single queue of events, and each event could be any type", and then each subscriber has their copy of that queue, then every subscriber has to process every event in order to decide which events it wants, and which events it can ignore. That's bad - every system is now trying to process all events from every other system, even if that just means "so it knows that it can ignore it".
S, we stick with separate topics. But now we can't control the order in which subscribers process those events. If some system is subscribed to both orders and order lines, and it happens to process the message in its order lines queue before it processes the message in the orders queue, then it may not be able to ingest the line message - for example, if it is using a relational database, it would get a foreign key violation.
You might say "well it can just insert a default order header when it receives the line, and then update the order header when it gets the real order header". But it's not always obvious what those default header details should be, and if you're working with some vendor system, you might not even be able to support that behaviour.
Another approach is to say "that's ok, the order detail will fail to be ingested on the first attempt, but we know it will retry. Eventually the order header will arrive, and after it does the retry on the line will succeed". This does work in principle most of the time, but it's a bit wasteful. And there are some occasions when it won't work. For example, let's say I create the order, then create the order line, then delete the order line, and then delete the order. All of this happens in system A. System B will receive 2 messages each on 2 queues. Let's say it processes the order header queue first. It will create the order, and then delete it. Then it will receive a message to create the order line, but it will never be able to ingest that message, because it has already received the order deletion event. So system B is now blocked on the order line processing queue until the retry decay eventually gives up entirely, which could mean that its order line queue is blocked for a long time. And it can't simply step over that line level event and process the next one instead, because on any single topic events *must* be processed in order.
OK, so a single topic which contains all events across all schemas has big issues with data volumes (because the entire queue of events is replicated for every subscriber) and impacts on subscriber performance (because every subscriber has to process that entire queue), but separate topics which provide simpler schema validation and does not require subscribers to process every single event might create logical problems with ordering.
I am not aware of any "theoretically sound" solution to this problem. There are other problems as well, which have similar implementation headaches.
That's just one of the difficult implementation details that I struggle with. I still think that this approach to shared state is definitely the right way to build a distributed system. I just don't think anyone has come up with a completely satisfactory solution to implementation details like this one.
Well actually, I am aware of one "theoretically sound" solution to this problem - because I built it as a proof of concept. But as far as I know the idea is not "natively" supported in any event brokers.
The idea was to have a "control" queue for each subscriber, where every element in the queue is a pointer to some other queue that contains the next message in order. But that has its own implementation difficulties. When I built it, I built it entirely using SQL - because it was just a proof of concept. It used tables as queues, and made use of sql server service broker for transactional decoupling. And it works, at least in principle. But I have no idea whether it can be written in a way that scales, it was just a theoretical proof and was never subject to a real production workload, and it does require some fancy logic in the messaging side.
Messages with ordering dependencies have to be in the same queue. You could have a message like "Order Update" that can have subtypes of "Order Create" or "Add line item".
@@jnnnnn The ordering dependencies here come from what are essentially foreign key relationships in the source system. In a well designed relational database, those declarative constraints tend to chain quote deep: invoice lines depend upon order lines, order lines depend upon orders, orders depend upon products and customers, and so on and so on. You can't put all of that into the same queue.
I understood every word she spelt.
Thanks great talk
Very well explained! I also want more people as passionate as you are :)
It would be good if you rename the video to "Microservices: Event driven architecture". This current title is very misleading.
I thought I might learn something new, I already knew about event-driven systems.
What about the first 20 minutes?
Nice video mam
Watching video 🔥
Does anyone recommends a recent presentation to enlighten me in this one database per microservice paradigm?
There's a blog post by Michael Nygard called "Services by lifecycle" that might be up your alley
@@Trv3GuY thanks mate, gonna take a look
@@Trv3GuY ju
You can watch "Monolith Decomposition Patterns" GOTO 2019 talk from Sam Newman" who was writter a pair of books about Microservices.
ua-cam.com/video/9I9GdSQ1bbM/v-deo.html
P.S. Microservices were suppoused to have it's own database so that they can be deployed independently but the migration to this ideal architecture state is complex. If not some parts of the database can become part of the contract.
@@Trv3GuY gh d e, tsTs, if LG udxotzyrxudz Xbox Zita xor coz, ha Xbox ixtz
Really good talk. Concise. Thank you.
Great session! Thank you :)
Excellent content. Thanks!
Awesome content..Thanks
Apka voice amazing
Good
If every microservice calls for its own database, expensive database vendors like Oracle survive?
Can anyone explain me what this video was all about?
I can share secret: micro services is not about DDD or kafka or databases, micro services is a about traffic control.
Micro...microphone problem
We can
A beautiful Tibetan singer has released her latest song Zom Zom. Must watch
I mean who's even hosting multiple microservices without a gateway or a proxy. That's dumb.
Nice ad
I'm sorry for u guys
Ben shapiros distant relative
Do you help me
भौजी का बोल रही है
😆😆😆😆😆😆😆😆😆😆😆
Who Slendrnina, Granny, slenderman, Angelina. Say
great talk, hate to say it but her accent is very thick and this could use better than auto generated subtitles
If you really hate to say it, maybe you could just...not say it?
@@caneminops2595 I think they're saying that this video should have had proper subtitles written by a human. It's a valid point about accessibility IMHO.
What is this????????
Very bad architectures advocated here.
... the accent is very off-putting
Good