 Hello, everyone. Yes, there will be dwarfs. No, not yet. Unfortunately, as Mo Duffy says in the chat, there is in progress a coloring book for a venture of an architecture from Red Hat. And I've been participating a little bit in it, obviously not in the art or in the content, just in the kind of technical review. Smarter and more talented people than I are working on the actual drawings and the content. So this talk is about event-driven architecture. And then I realized I messed with the colors yesterday. And so later on, there may be some challenges for someone who is blue-green colorblind, which didn't occur to me, and I don't have that fiction, so I apologize in advance if you can't read it. But hopefully my pointing around will help understand what the picture is. So event-driven architecture under mostly the name like serverless and service mesh, and those of the two that kind of come to mind most quickly, has actually been around for a really long time. There's been, it's kind of funny if you go back to old school Microsoft development into what's called COM, which was the component object model. It was actually an event-driven architecture. The way it worked, basically you had a thread that was kind of sitting around and it would pick up events and then respond to them. And that was kind of how Windows worked. And then they expanded it to be distributed with the brilliantly named DECOM, which was Distributed COM. And what was I going to say? So except that Distributed only meant within a Windows network. So that wasn't exactly terribly useful for a lot of scenarios. So actually way back in the day, a friend of mine and I actually built a DECOM over HGP transport layer so that you could still use DECOM in, you know, if you were a Microsoft developer and you had all these tools like things like Visual Basic and the Visual Studio environment and they would still work but over HGP. So yeah, so keep in mind, event-driven architecture has been around for a very long time. And we're going to talk about how it works mostly like today. And then I'm going to try to show you some demonstrations of how it works and where it kind of fits. It's a difficult thing to demonstrate. I don't know if you saw the keynote that we did a little while ago. But there's not even great tools out there to kind of understand what's going on in a, you know, kind of a microservices architecture except like one of the code smells that was discussed, for example, was kind of the reduction in the use of something like a service bus. And, you know, the reason for that is because you want to kind of have events kind of going across the entire environment so that you don't have to be limited to just the events coming across the bus. So you end up with a kind of very complex, you know, in somewhat difficult to understand environments. And so there's a lot of rapid work going on to try to help people visualize it and understand what's going on. And, you know, hopefully we'll get there sooner rather than later. But we're going to show a little bit of some of that tool chain as well. And, you know, my timing is a little off. I was expecting this to be a little bit longer talk. So hopefully I'll be able to kind of fit everything in and leave some time for some questions. But long story short, on this slide, I wanted to point out that, you know, I spent around for a long time. Sometimes it's gone under other names. So I kind of mentioned COM and DCOM. It wasn't really called event. It certainly wasn't called an event driven architecture. It was referred to as events. And then, you know, things like service oriented architectures were really going in that direction. CORBA also worked this way, sort of. So kind of like we have a lot of things that are kind of around this problem. And we really are starting to see it come to fruition. You know, there's not a whole lot of implementations out there, like people who have it in active use. But there are, but the tool chains are there and it's starting to become pretty relevant. So just kind of, I like to kind of give a broad example of something that has taken place that, you know, kind of illustrates whatever I try to be talking about. So in the time for a story, once upon a time, many years ago in my personal career, obviously all names will be held to protect the innocent. We had a project. I was working as a software consultant at the time. And we had a project where all our customer had a problem where their managers had to do all these different kinds of what were referred to as just approvals. And if you're a manager in basically any organization, you probably have this experience, right? You have to approve, you know, vacation time, you have to approve invoices, you have to approve expenses, all these things. And nine times out of 10, they're in 40 different applications. Or it's in, you know, Oracle apps, and it's just a horrific experience anyway. So when we talk about this, you know, project, what the challenge to us as a consulting organization was was to, how can we simplify the user experience for all these managers? And when I say all these managers, this company, I say Fortune 500, but, you know, I think they had in the division, we worked it with 30,000 employees, give or take. So pretty big company. So we went towards an event driven architecture, basically. So what could we do, right? And so, well, okay, we could build a whole new application that does the approvals for all these things. Okay, that's got a whole bunch of problems with it, right? So basically, Greenfield applications, as they're referred to, is when you go and like build something brand new to solve a problem. Greenfield applications tend to be the riskiest kinds of projects to take on, because they are expensive. They are often particularly pre-agile methods have a very high kind of expense curve before they actually resulted in anything. And so they tend to be really, really risky. And consulting companies don't really like doing really, really risky projects, because that means you don't get more projects. So we wanted to shy away from that. Our customer also wanted to shy away from that. So another solution is to go to SSO solutions. And so a single sign on service would simplify at least the access to these, you know, literally 20 something applications, which would be nice, but doesn't necessarily meet the kind of full kind of user experience needs. Sorry. And then lastly, and this is going to further date myself, one of the proposals and one of the very popular solutions to this kind of problem at the time was a tool chain called a portal. And what this was was basically, you know, imagine an application, you know, a web application that's like just a whole bunch of square iframes, right? And then there's all these individual applications behind it. And then you kind of go and click on one of the squares. And you might be able to do one little interaction on that first square, but normally you would go and click into it. And then it would actually take you kind of into that application. But the idea was you kind of have the SSO component. So it's a single sign on, but it's also kind of surfacing each app all in the same user experience. Lots and lots of problems with that. That's why they eventually died. But, you know, they, they, you know, worked, you know, it's just, it was kind of tough. So moving on. Well, so we can think about using events. Okay. Well, so first of all, what do we mean by an event? And as you can see here, clearly, we must be talking about a, you know, a rock concert, right? Is that's an event. But in fact, we aren't really calling that. We are talking about things that, you know, kind of trigger a response. And so when we say an event, you know, if you think about it, there's lots of events in the real world, right? You have lights changing, you have, you know, turning lights, which on and off is an event. You know, trying to trigger the crosswalk is an event. As far as I'm concerned, I think hitting that button doesn't really do anything except make you feel better. It's kind of like the closed door button in the elevator just doesn't seem to actually cause any change. So we have several different types of events when we talk about technology events. And there's actually some references at the end of this deck if you want to kind of go read more about it. And I'll share the deck in the Discord room after the session's over. So an event notification. So this is kind of like a light switch, like or how a light switch feels, even though it's not actually working this way in practice. But it's just the notification. So this thing took place. It doesn't necessarily carry any information in the event itself. So it's just the notification. And then another type of event is what's called an event carried state transfer. And this is the trigger, but also all the information about the event, right? So, you know, so the event and so the difference between these two, right, is that the all of the information that you might need to process the event is carried in the event itself. But obviously the event itself is then a much bigger payload. So you have to have a different kind of channel to deliver it. So there's trade offs between which type you want to use. And then the last kind of term is event sourcing. And this is where you have a state change event. But the key to this is that they're serial. And so the state change events must be processed in order, as well as they have the benefit of if you run the same order of events again, you will end up in the same state. So these are I think the ones identified by Martin Fowler, like a bunch of years ago, and I referenced the article at the end. And so just to kind of give you some language to talk about the different events or event types really. Now let's talk a little bit about this kind of going back to the story of our our little example system, right? So when we walk in the door, we say, okay, you have this expense system, you have this invoice system, you have all these different systems. So what we're going to do is we're actually going to put an interface into those systems, you know, somewhere in touching the business layer. So if you look at this picture, kind of here, you know, if you notice when we build that expense listener, we don't build it going against that first tier of a three tier architecture, we put it instead into the business tier of that architecture. So in other words, all the business logic should be encapsulated right in kind of that middle layer. And so if we call into that middle layer, we'll have the advantage of the business logic without having to fight through things like html screen scraping, etc. We can do that. And it's awful. But when you don't have control over the system, for example, sometimes when you're trying to build something like this, you don't actually have access to the business layer, right? There is no API there. So in this particular case for this particular project, for some of them, we actually had to kind of build the business layer or build the API into the business layer. So we did that. And then we built these listeners out in front of it, so that we could fire events into the listeners, and then transfer them into the appropriate system to do the appropriate thing, whatever that might be. The other thing what we wanted to do was, as again, any manager knows, right? This is the what feels to be a lot of the time, the least critical part of your job, right? Nine times out of 10, you're trying to put out a fire, you know, you are trying to maybe actually sometimes you actually have to deliver on your own kind of individual contributor work, you know, all these different things. And so approving an expense seems like just overhead, right? It's such a pain in the butt to do, you have to do it all the time. But in fact, for the person who's receiving the expense, right, it's very, very critical. So what we wanted to also build into this system was the ability to kind of fire and forget, right? So once you clicked the button that said approve of that expense, we wanted to guarantee that it would make it over there. So now the thing is, is that once we kind of start to build an architecture like this, then we can start to extend our system in really interesting ways by introducing new kinds of events. Let's say, you know, as your organization grows, basically, the types of approvals and the number of approvals goes up, right? So, you know, many people, again, kind of more in management than in individual contributor levels, they'll have like a budget approval process, right? They have, you know, $5 that they get to spend, you know, over the course of a year. So that way they can build or they may need to be able to approve that budget where it's going to be allocated, etc. And so what we can do, though, is that we can start to add new listeners into that same business logic system and keep them independent. And hey, look, now we're starting to have microservices, right? We're starting to have, you know, all these different kinds of things that we can start to then get even more interesting. Because what we can next do, and we start to drive off of this event driven state and off of this microservice architecture, we can actually throw out the user experience component of our expense system. We can stop maintaining it. So we have one less piece of software we have to deal with, because nobody's using it, right? They're all going through this kind of shared front end, because the user experience is better. And then it's just firing the triggers into the actual system. So you can slowly retire the kind of UI aspect of those systems. And or at least this is what we did, right? But so these are some of the advantages you get to driving through into this kind of event driven architectures. And so in particular, I think Service Mesh talks about this particular kind of aspect or role or whatever you want to call it, you know, that I'm kind of giving examples of here, where what we can do is we can, you know, kind of make an actual application look like this picture, right? We can actually look at how those expenses, sorry, how those events are traveling through our system. And given that we don't have a lot of time left, you know, I'm just going to kind of mention, you know, it also encourages even more feature set when you start to think about your architecture being an event driven one, is you can start to do canary rollouts, which is when you say, okay, only a portion of my team is only a portion of my customers, whether that's internal managers or actual customers would get a, you know, this new version of the application while you try it out and make it see if you can make it work. You know, all these different kind of features that start to roll out. And so assuming the demo gods will favor us, I will try to show you an example of this in OpenShift. This one, maybe. All right. And so with the kind of, so Service Mesh is not only a concept, but it also happens to be something we ship, we ship product called OpenShift Service Mesh. It is actually based on a set of upstream projects called Istio and Keali and Yeager. And while the real work in a sense is being done by Istio, which is what is actually allowing for this pretty picture to occur or the slides that I was showing you a minute ago to occur, it doesn't visualize it, right? It just says, you know, it's doing all the stuff in the background, right? So what Keali does is lets you visualize that experience and also do some level of interaction with that experience as well. But importantly, and I'm going to see if I can make this any bigger for you all. And so we can do cool things like, I don't know if that helps. Just a friendly reminder that you have seven minutes left, okay? Okay. Thank you. Yeah, I saw your 10 minute warning. I have been doing a Twitch show for the past, I don't know. Actually, it's quite a long time now, six or eight months. And so I've gotten very good at reading the chat while talking. So yeah, it's kind of funny. But what you can see here is we can actually do traffic animation, right? And I actually have traffic going through here. And I think I'm going to run out of time on trying to move it around too much or whatever. But you know, the idea of we have all these different events that are taking place that are passing through the system. Let me slow down a little bit or it's just going pretty fast. So the events are going through the system. And then we have the ability to kind of rearrange how some of these different components work. So if you notice there's a V1 of this recommendation engine, okay, well, what if I want to introduce V2? Well, I can introduce a V2. And in the Canary rollout that we were talking about, we could say, okay, let's move 5% of the traffic there while we make sure that it actually works. Or we have a V2, but we're not actually sure if V2 is better than the old version. So why don't we do what's called red-black testing or blue-green testing and kind of just share the, and sorry, and see if the characteristics of the users change based on which one they land in. One of the classic examples of this, which I thought was super awesome, was I think the Hillary Clinton campaign when she ran for president, they did a system where they did an AB test or a red-black test. They're basically all very similar, but depending on what layer they're in, they get a different name sometimes. But they did a different testing with different size buttons around their donation. And they had a material impact in their donation dollars when they changed the size of the button. I think the button size increased. But as you can see, like I can now, using an event driven architecture, I can introduce new things anywhere in this pipeline. And like I said, I was thinking we had the longer session, so I was going to try to demo moving some of these things around. But this is kind of the idea. You can find lots of other demos of this going on. And so I wanted to kind of move, I'll move back to the slides quickly, because we are almost out of time. And just because I also like to give the attributions for the pictures I used, but then the references and kind of further reading, hopefully this is interesting enough for you to go and go and check out some of this background. Martin Fowler, if you're unfamiliar, is a real thought leader in technology in general or software development in general. And so his stuff is really interesting, but can be very dense. So I hope you find some of these things useful. Like I said, I'll share the slides afterwards. You don't have to like take a picture or something like that. And let me flip it over to say, do we have any questions? Is there anyone who wanted to talk about something? Well, I hope that gave you a decent... Oh, well, I could talk a little bit more about serverless. So the serverless part of it is what we're having here. And I didn't mention the kind of word, but the serverless aspect is really you're just creating this thing over here, right? Because the serverless system, it's not really serverless. It's a fire and forget operation that happens to take place on a server, but you don't experience it. You don't have to maintain it or whatever. So as soon as you organize your company around kind of this expense component, let's say it's the expense listener, the budget listener, the elite response, all kind of independently, they are just triggerable events, right? And serverless is just kind of, in my opinion, a kind of a fancy way of talking about doing an event response in a way that you don't have to kind of manage any of the infrastructure that's behind it. So while you'll see things like Lambda and such as ways to implement this thing, really it's the concept that matters, right? It's that you're firing off an event and it's causing things to happen. So the next question there is can we have serverless with state? You can. It's much more expensive or it can be more expensive. So in the current implementations that you see in things like Lambda or in Knative or any of those solutions, you generally speaking are going to want to store your state in some sort of back end, right? So in some sort of database. However, using one of the methods that we talked about early on where you you can actually carry your state along with your event. So it depends on what you mean having serverless with state. Generally speaking, pushing as much of that information to the client is a good idea, but it isn't always possible. So stateless always better. Stateful can be done and sometimes can be pushed to the client. You know, if you see well executed like single page websites, you will actually have these massive cookies or even the client side data store in the browser itself, which is actually usually carrying state. The thing is then you also have to introduce things like encryption and security and stuff like that because you don't want to have any dangerous data there. So hopefully I answered the question. Hopefully I gave you a brief introduction to why you might want to take a look into event driven architectures implemented with, you know, service meshes or serverless microservices, you know, microservices in general and hopefully that convinced you and we are officially I think out of time. Yes, you are Langdon. So spot on that. So this is a fascinating topic. Unfortunately, we didn't give you enough time, I think, but yeah, I totally, I, you know, honestly, I misread it originally and thought it was a 40. They always say, you know, leave the room with them wanting more. So I think you've done that. Exactly. Exactly. I hope so. And, you know, like I said, I'll be in the discord probably for the rest of DevConf, but I currently have session room one open, but feel free to tag me. And I do not have a longer version of this talk because this is the first time I gave it. My plan is to kind of keep building it out. In fact, because I have a number of internal like Red Hat people who I'm trying to give this talk to and I want to do both a short version and a long version. So I would welcome that. I think it's a fascinating topic and you're a wealth of knowledge. So thank you very much for the session. Thank you very much for continuing to monitor discord. So people have a lot of questions. They can find you there. And I wish everyone a good day and stay tuned at 430 Central European Time for Kubernetes native with MicroProp on Quarkus presented by Roberto Cortez.