 Okay, so thank you very much for the introduction and it's Actually, I hadn't expected this many people in the talk. So because I've given this talk before a pike in italia. It was kind of the same and also the same kind of expectations. So I was wondering Why people are so interested in this and we're gonna get to that in the talk I'm first gonna give you a short introduction of what event-driven architectures are all about And then in the second part, I'm going to talk about how you can use Python for these things So first a bit of a speaker introduction I'm Mark Lamberg. I am based in Düsseldorf in Germany. I have a consulting company a Python consulting company We're currently looking for new projects. So if you have anything for us, then please talk to me I make a living as a senior solution architect. I also help startups for example as a CTO And also some coaching. I've been active in the Python community for a very very long time Did lots of things. I'm a core developer Bureau Python Society fellow Python Software Foundation fellow and I also founded a user group that we have in Düsseldorf in Germany so Let's assume that you want to build the next big thing, right? So let's say another Facebook another Google another Amazon And you you have this great startup idea, but you don't know really where to start Although you have to have a Picture of where you where you might be heading So you have to plan ahead to be able to scale up and for example take lots and lots of orders If they come in or take lots and lots of requests coming in So you have to architect your solution in a way that actually scales up very easily So you don't get into bottlenecks. You don't run into any walls during your development And you have to pay attention to a number of things. I listed some of these things on the slide So first of all scalability are a talked about that You have to horizontally scale which means that you have to take as many requests as possible You also have to be able to scale vertically So you have to basically be able to adjust your stack to new requirements If your Solution is supposed to be you know running for an enterprise for example Then you have to prepare for the enterprise and being Enterprise compatible means that you have to look into compliance observability accountability governance All of these things so that is something that you should keep in mind right from the start and you should design your system in that way Very important is observability. That is something that often comes as a hindsight observability basically means that you try to Make it possible to look into how your system operates how it works At you you need to look into that at at runtime So you need to be able to to connect to your application and see what it's doing But you also need to keep logs of everything that's been done for auditing purposes later on So that's observability. That's very important. I'm mentioning this because this is one of the Weak points of event driven architectures. So there are two architectures that you all probably know how many of you know rest Pretty much everyone graph QL Almost everyone. That's good. So both of these architectures are what I call synchronous because Essentially what you what you do is you call from your front end to the back end You wait for the request and then you get the data back. You get the data back in two different ways rest is basically Statically defined. So every every API that you you call there has a certain Returns a certain number of types Whereas and a certain number of data whereas graph QL is much more flexible. It's it's a lot more Like for example talking to a database on the server side So you can it's very flexible when it comes to doing queries And so it takes away a lot of the complexities that you have with rest if you have a constantly changing database schema in the back end So if you want to start something new rest is always good for for simple things graph QL is Excellent if you have this use case where data schemas can change Both are difficult to scale though if you want to you know go to some kind of like Google or Facebook kind of scale Then this is really really hard and then comes event-driven architectures either So either is different in that it's asynchronous So it's not like you you send a request somewhere and you get something back right away and you can wait for it It works completely event-driven as the name says so you you have an event The event gets handled by many different systems that listen for these events And then these systems can react on that event and generate new events And so what typically happens is that? You have a front end that talks to a back end the back end could then be rest or could be graph QL But it's not actually doing the action of the processing that's behind that request It only takes that that request and then generates an event And then your your event-driven architecture then goes and processes this event All kinds of different subsystems talk to this the endpoint that you have there and no, sorry wrong it Generates the event and then the The end point waits for for the final message to come back To that endpoint to to return something to the user. That's a better explanation So the nice thing as I already mentioned is that you can combine it with rest and graph QL So you don't need to have your whole system designed like that You don't need to have your front end generate these events and You can very easily integrate with existing systems that have a rest or graph QL interface The nice thing here with with either is that it's very very easy to Extend it's very easy to scale up because you can just add more technology. That's listening to these events It's also very easy to replace certain parts in your system because there's no tight coupling It's all loosely coupled So you just need to have or make sure that these new systems Understand these events and react accordingly It's actually very old architecture it was Well, at least that's the first time I heard it was in in the 2000s may actually be even older than that And it was part of an architecture called so was service oriented architecture. That was a hot thing at that time How many of you know event-driven architectures? Very few so that's that's good So I might actually Tell you about something. That's new You may not be aware, but you actually probably all using event-driven architectures as a user already Because if you look at the your OS all the the UI Technology in your OS is actually event-driven And if you're ordering on you know services like Amazon then same thing everything is event-driven So this slide shows the the main concepts of event-driven architecture. So of course everything has to communicate with each other You have producers that produce events and you have consumers that consume events You typically have a broker in between those two so that you make sure that the communication actually works And there are various ways of how these consumers can listen to events and how these producers can Put events into the system in order to make think to make sure that that everything gets handled properly You typically organize the events and topics and as I said everything is fully asynchronous so No one is waiting for anyone and you can you can just have all the the consumers just do Just look on on that topic for and watch for new events and then they can just take the events and Process them and do something with them So events are typically in an actual implementation of the architecture are typically implemented as messages and And the the type of messages that you can expect is for example something happened or a state change somewhere Or you can have initiated command. This is very different from what you have in typical kind of These these queue system Structures like for example, if you use Apache Kafka, then typically what you do is you process data You don't process things like commands. For example, you don't process or necessarily process things like a state change But you just want to take data and you want to process it and then put it somewhere maybe act on it The message message themselves they cannot be very large because you want to be very efficient So you encode them you typically also compress them and whenever you have something that's bought data like you know Images or voice files or videos or whatever then you would typically manage those in external storage For the encoding that you use on these messages You have a number of common formats that are being used the the most common one is the Apache Avro format Which is the default for Kafka. I'm going to explain what Kafka is a bit later It's one of the brokers But there can also be other types of you know messages. For example, you can have Jason you need to be Make sure that everything is it's nicely typed and also ideally signed because you want to make sure that your whole infrastructure internally is secure and Because you want to have traffic, you know not not generate any bottlenecks compression is also something that you can use to speed things up Now, how do these messages go from one end to the other so like I said everything can be organized in topics And then you can have you have two different mechanisms of how to manage the Distribution of these messages a very popular one is a published subscribe or pops up. How many of you know that one? Lots okay, so I don't have to go into details. That's great There is one Downside with published subscribe is that messages cannot be resend to new subscribers? So if a subscriber Enteres or new subscribes to a certain topic later on they won't see the history of messages And that's something that a second type of distribution Handles which is called streaming so in the streaming case The broker actually stores or buffers messages for a certain amount of time And so you can basically look back at messages that have already been sent earlier on and so it is possible to for Consumers to subscribe to a channel and then see what's already been in the queue And then maybe take older messages from that queue and work on those it also enables automatic replay Which is nice in case of errors. Let's say something goes wrong, then you might want to replay a certain number of messages this whole architecture then Introduces the the decoupled sending and receiving so you you don't have to have the brutusers actually know who consumes their messages And likewise you don't have the consumers know about who produces messages so This may sound a bit awkward, but it actually the the Consumers are only interested in the types of messages. They're getting they're not really interested in who is sending them, right? So you have two things that I don't know if you can see that it says at the bottom It says separation of concerns and encapsulation those are two design Goals that you would typically want to have in your architecture So what kinds of message brokers can you have the most popular one? I guess is Apache Kafka, but there are lots and lots of others as well Apache Kafka is basically a messaging system where you put in data. It's extremely fast and It's it then you know disseminates the data to Subscribers for example, you can also set it up in a streaming way So that you can handle both of the cases that I showed here If you are more into specific protocols for example a MQP, which is used in finance a lot You can use rabbit MQ for this if you're more into iot then MQTT is a good protocol for that And you have Apache active MQ for this or if you want to start well very small Then you can use mosquito, which is a Python implementation of this And of course you have the cloud providers. They they all provide some kind of pops up interface or Even more basic technology as AWS SNS There's some older variants as well. And this is basically how I learned about this architecture. It's called IBM MQ series Does anyone know that one? Yeah, very few interesting. This was used in banking a lot and I rounded the two thousands Many banks basically processed all the transactions through MQ series because it provided certain Security is around how you process messages and this is on the next slide because Implementing a broker and likewise selecting a broker is something that needs to be carefully done so You want to make sure that all the messages actually do get delivered, right? That's one thing. That's very important You also want to make sure that every process every message gets processed exactly once and not multiple times So let's say you order something on Amazon. You don't want to get everything twice, right? Failure modes are very important Because something of course will fail in all, you know, dynamic systems something will eventually fail You have network issues. You have processes not working correctly. You have an animal back ends going down So you need to make sure that the the broker can help you with these failure modes And you need to figure out which message size to use So you need to figure out whether to put the actual data into the message or not whether maybe you just put a reference into the message And that's a trade-off, you know, the bigger the messages get the slower your system and The the downside with putting references in there is that all the different Actors in that system will then have to go to these You know the the fixed storage the s3 or whatever of database and actually get the data before they can start processing Now another big thing is that you need to tell everyone about how these these messages get processed And which messages are available and which producers and consumers actually do Create these messages and there's a standard for this which is very much like the open API standard Do you know the open API standard? This is basically something that was developed for rest. It was called swagger before It's a machine readable, which is very nice. So you can actually have discovery in your system and async API was Was created to basically follow this kind of standard except that it's it's adapted to async processing and publish Subscribes so you can you can see what's what? the consumers and producers What they provide and you can look into the types you can look into the messages the types of messages that they send is a relatively new standard Unfortunately, it's mostly no JS and Java based. So Python does not have a you know, big role in it And that's you know, also part of why I'm talking at the conference about this because I would really like Python to have a bigger story in this async API But yeah, let's do a recap of the architecture so event driven architectures really Actually quite easy to understand. I think you can split applications and loosely couple of components Which is very nice for scalability purposes. So you can easily scale up and scale down everything as you see there on the on the right You have a rest bank. You still have a rest a back end But the rest back end doesn't actually process anything anymore It just creates messages and takes messages and then you have something called an order manager in there Which then makes sure that all these messages get properly Processed and also that all the different stages that you have in there are you know Create message take messages return messages and then it also sends back to the the rest back and the reply Now I have to check the time If Servicemen's left Okay, I have to speed up this a bit. I wanted to Compare rest and graphql versus either so let's it's just quickly run through an order that you have in a web shop So firstly the rest graphql interface. It's synchronous The the back end system that you have the web back end has to talk to lots of different subsystems in such an order system So you have a payment system fulfillment inventory Q-order handling delivery, what are many more probably some fraud detection system? Maybe the problem with that is that all these these different subsystems then have to be Communicate with directly from that particular back end And that has to happen every single time you you get a request now if one of these subsystems goes down Then of course the whole request goes down if if you want to update one of these subsystems With you know, let's say a new data structure Then you always have to go to the your web back end and then update that as well So it creates more downtime if you do these things And there are you know challenges with With handling failures with handling, you know changes if you have a single point of failure basically in your In your front end and ideally you don't want that so how does either work either is more flexible in this respect? As long as you have one of these auto management systems sitting In front of this and then managing all these different events You can easily scale up and scale down all the different components So let's say you get lots of requests to the inventory service then You can just you know add more workers that list are listening to these messages and then your whole system then scales up Code management is also distributed so you can make changes to the different parts in your system without actually affecting the web shop And that's very nice because you can also handle upgrades much easier You just you know you put up new workers that have the new code and then you slowly shut down the existing workers that are still working And so everything is nice There are some challenges of course I mean every every architecture every system has some downsides, right? So one of the big downsides as I mentioned early on was it's the debugging of these systems because everything is dynamic Everything can can happen at undetermined times and without necessarily keeping the same order You have to you know make sure that everything gets locked properly You have to ideally have a central lock server that takes all these locks so that you could you can reconstruct Processing later on for debugging purposes and there's another thing that's the organizational challenges because everything is decoupled It's very likely that in a larger organization You will also have different teams working on these things And so you need to make sure that the organization communication is working properly an Async API is something that really helps with this because it documents how things work What's the different services expect what they send? And it makes it much easier to communicate things So the second part and that has to be really quick Unfortunately, that's also not too much I can tell you about this except that Python async support is absolutely fantastic for pop-up kind of interfaces and I'm really glad that we have this now in Python If you have something that is not async compatible It's always possible to use threads to then you know talk to external libraries that may not Support async so that's not really a bigger big issue and these external libraries don't need the guilt So you don't also don't have any guilt kind of challenges So what about this this documentation? Specification async API well there isn't much To say the least and the async API community itself has too much focus on Java and no JS So we should really do something about this There's a tool called async API that does have some support for Python But it's really simple and it just works for MQTT kind of installations like you know small home assistant kind of Technology So it's not really up for scale. So basically you cannot use it Everything has to be handwritten There is some support on pi PI there are two packages. I found one is the more general one is async API package that helps you with reading these specs and then providing API's and it's another one that's provides ways of Publishing this kind of a spec to your internal network so that you have introspection and Discovery, but both of these developments have stalled. I don't know what's happening with there Some perhaps we need something new on the good side The the different systems that I talked about the different broker systems They all have interfaces in Python all of them and these are used a lot So it's definitely possible to roll your own and to work with these directly So you don't have to rely on these async API modules being available You can just tap into this directly and this is also currently being used so conclusion Roll your own is definitely possible and it's also used by a lot of companies We do need better support for either in Python We need more people working with the async API specification organization so that we get a foot in the door there and We also need more Support in you know popular interfaces that we have in Python to to help us with this Right and so the main takeaway is never stop to learn. I hope you learned something in the talk Maybe a bit at least and always try new things because there's lots out there lots to be discovered and I Often have the feeling that we are a bit of you know living in a bubble in the Python world We're not looking outside. For example, we're not looking at all the great Java stuff That's out there like if you go to the Apache Software Foundation project page. There's so many projects. They're using Java It's great software and most of these projects have Python interfaces. So you know Do have a look around and shop around Thank you. Any questions? We have time for questions and can we please line up here for questions, please? Hi, thank you for a great speech What I always struggling with with that kind of architecture is that you are usually is not a synchronize but synchronize Let's say that case when you make an order for example in Amazon So what we should return to the user because You put an order, but you don't know it's gonna happen or not because there are lots of events Happening in the background. So I cannot just tell the user that the user was played because I'm not sure about it So how to solve these kind of situations in the on the UI part actually So on the UI part typically what you can do is you can you know show that something is being processed If you for example go to one of these shops like Amazon for example or Salando or whatever There's a processing typically happens so fast that you don't as a user you don't really notice that You know something is going on in the back and which is actually asynchronous, but it happens so fast So it appears to be synchronous If you if you do something else like for example, you book a hotel or you book a flight Then you actually typically see that something is happening and you have to wait for the processing to finish and what they typically do is they You know entertain the user in some way show how many you know Hotels are searching how many flights are searching these kinds of things, right? What's happening in the background is asynchronous as well So it also uses these kinds of event so you would say that on the back end side You just wait for the final message Yeah You I mean for very long-running things like for example in in finance you often have I'm working a lot of finance in finance. You have lots of reporting Bad shops that are run and they usually take hours, right? So what in that case what you do is you just you notify the user by sending an email or a message to slack Whatever to then pick up the the request as the report And maybe one of the short question also about the postgresql I guess I was interested about it how it works. They're actually that Subscribed. Yeah, you have to look at the postgres documentation. It has a pop-up interface as well So you can actually use postgres as a broker. So it creates like events in a database It creates events that you can listen to and then act upon. Yes Thank you Okay, thanks for the duck Yeah my question is um, how to deal with lost messages or Lost confirmation of the messages that something was successfully processed And how do you even track the state and maybe do the repetition because the user really doesn't really care What happened in the background because there was a synchronous a synchronous But they really don't want to see double bookings or a confirmation that the booking was successful Even though it was not because of some internal glitch in the broker or where ever what strategies do you utilize to handle this? That's a very good question what you typically do is I mean if you want to do Analyze later on if you had any lost messages, of course you do logging and then you you try to analyze the logs if you want to inform the user about you know a Process not not really working out then you have if you have like an order system You can use this order manager to then inform the user about a problem in the system And you can also have an order manager roll back that transaction so that you don't have any double bookings Unfortunately, this doesn't always work. I mean I've had that experience myself for a number of times I booked a flight and then you know didn't happen so And I tried again and you know I Wasn't sure whether I now had two two tickets or just one ticket. So basically I had to call up support for that so this is something that Not always works out in an in an ideal way But you can certainly make it work if you have Extra systems that protect against this But it doesn't come out of the box. You have to you know actually implement this and think about it. That's the most important part Okay, thank you Yeah, good great talk. How do you handle time-based events things that aren't necessarily triggered by an action from the user? Time events like you know do something every every day at 3 p.m. That kind of thing or yes We use a venture of an architectures to manage like long-running processes and sometimes like for example like in energy A user comes on supply on a certain date and we need something to happen at midnight on that day right you can What you can do is I'm not actually I'm not aware of These brokers handling, you know the situation where you put in an event and you give it a time and then you say Okay, this event should only go into that topic at that point in time That's actually a good thing. I would have to research that whether that's possible or not. Yeah, I'd love to chat with you about yeah Thank you Thanks for the great talk. I have a question about the stability of Evanguin architecture What should we use like in terms of end-to-end testing and Integrational testing So for end-to-end testing you can if you have a web front and it's typically best to just start with that web front plant and put all the requests in via the web front end and then You can you can have checks in the in the back end that that events actually being processed And you can you can use that kind of approach for testing I would always recommend to do the testing both end-to-end so both using the web front end all the way to you know What what happens in the in the back ends? Where you check whether something actually got triggered? But also have full testing of course in each component that you have in your architecture, right? so a Good way to start with this for example is to basically do to start writing tests from top from the The top level so basically going in from the web and also from from the bottom level where you basically make sure that all the Different low-level operations that you have in your components work all right That's it for all the event-driven questions. Let's thank Mark Andre again, and he will be available offline to chat Right. Thank you