Effective Microservice Communication and Conversation Patterns - Jimmy Bogard
Вставка
- Опубліковано 31 лип 2024
- Orchestration or Choreography? Sagas or process manager? REST, RPC or Events? Are we just making this all up as we go along?
Once we move away from a single process to many services and processes, we immediately hit the problem that our services need to communicate with each other. The architect mandated REST! But then nothing worked in production. Then came events! And nothing ever completed.
In this talk we'll look at the problem from a holistic perspective - take the fundamental property of autonomy for any microservice-based architecture, and design how services should communicate so that they can still achieve their purpose in the world.
We'll cover basic communication patterns, where we run into problems with them, and how advanced conversational patterns can help. Finally, we'll look at some real-world scenarios for designing complex coordination and where conversation patterns can retain our autonomy and loose coupling.
Check out more of our talks, courses, and conferences in the following links:
ndcconferences.com/
ndc-london.com/ - Наука та технологія
Really nice talk! Maybe a nice way to remember the diff between orchestration and choreography is that in an orchestra there must be a director in scene (i.e the benevolent dictator) while in a choreography everyone "already knows" what to do.
By far, by far the best talk about that. Really really great. So down to earth, knowing that technology is here to solve real problems and not creating ones by possibility driven solutions.
And the examples based on real processes makes it so easy to understand.
Really great job!
Thank you. Cool interpretation and analogy of real world process vs virtual processes.
Great! many thanks ;)
Good talk. Thanks, Jimmy :)
Awesome video very well explained.
Please link to the GitHub repository you mention at the start
At 52:45 when discussing how to get the databases to talk to each other, two options are initially presented and dismissed. Linked servers (or more generally federated queries), and SSIS (or more generally ETL). But no reasons are given for their immediate dismissal.
Now, linked servers ARE bad as a rule, so maybe that one doesn't need much explanation. But *some* explanation should probably have been given anyway, because in my experience a lot of people don't know why federated queries are bad, which means they also don't know when they might actually be fine. And by the way, the problem with linked servers is *not* a coupling problem, at least not any more than it would be for any other solution. The primary problem with linked servers is performance, ie, pure IO load and query optimisation. And of course it's also subject to all of the issues caused by synchronous comms, like network issues at query time.
It is far less obvious why ETL is summarily dismissed. If you want to say "SSIS? Nooooo. Nooo", I think you have to justify that. Is it because you need the data to be updated in near real time? I doubt that's true in the use case presented. Are you really changing menus every 5 minutes? Bulk updates on some schedule - like nightly, or every few hours, are probably fine. Jimmy actually says exactly this just seconds later. Is it because you just don't like the particular technology that is SSIS? I can get behind that, the IDE is absolutely terrible, and actually building data model transforms in the visual designer takes way, WAAAAY longer than it would in pure code. But that's only an argument against SSIS specifically, it's not an argument against ETL in general.
Because this talk is about microservices. And the context is based on database per service pattern.
@@vinniehsu7092 LOL. Yes, it's a talk about microservices. It's advocating for the use of them. But if you want to advocate for the use of something, you have to *actually do that*. If I was presenting a talk on, let's say "Here's how to be a douchebag", and you came along and said "but you shouldn't want to be a douchebag", according to you, it would be adequate for me to say "but this is a talk about how to be a douchebag".
It's so pathetic. Some people can't just get what microservices is all about.
@@vinniehsu7092 Since you have failed to address my argument at all, and have chosen a complete non sequitur in response, I accept your surrender.
47:45 the truth
You know Jimmy :)
The eatable james periodically start because bath frustratingly overflow since a upset cross. undesirable, knowing cushion
bla bla bla...
wow, this guy believes in Corona as a real pandemic