 thank you to Hugh for making such a nice introduction of me, so there's no need for me to talk too much about myself at this point. But one thing I think for sure is that I'm just very passionate and I love coming to, you know, being an advocate, I travel to conferences and meeting people, understanding what your needs are, and then of course I'm advocating too. And these days I'm doing more about event streaming, things in that space. So that's why to even today, let me kind of look for my clicker. Where's the clicker? Oh, right. Sorry. So I'll be talking about really examining about, you know, a bit deeper about terminology. Is it just semantics? Is it reactive or eventful? Or are they actually the same? And so, yeah, so with that, let me start. So, so just to give you a background, I when I joined IBM, like three years or actually, I should say 2018, so before COVID, way before COVID. So I kind of got asked, there was a, at the time, IBM had a partnership with LightBand. So that's how I started working with some ACA integration and then advocating for that. And that's how I met Hugh and LightBand, all the great folks there. And there's just been such a great, you know, friendship and reactive has always been dear to my heart. And it's just something about it, right? And just working with events, you know, in that space, although in the reactive though, I'm noticing that the word events has never been really like formally kind of put to the forefront somehow. So I kind of get into, that's why I want to get into this topic. Now I'm working with the event streaming specifically Apache Pulsar, which I actually will have a talk this afternoon too. So with that, let me kind of, let's go back to some basic first. So what is reactive, right? I started looking into some basics. So reactive basically refers to distributed applications that meet, you know, the kind of respect that for core principles, attendance of reactive manifesto, responsiveness, elasticity, resiliency, and message driven. So I don't need to explain too much. Everybody in here already expert on that field. And, but then the thing is too, it's interesting, as Hugh has mentioned too, initially the reactive manifesto came out and that's what I was going by. But then I actually visited the site reactive manifesto and realized there's reactive principles and that's been like added to that, which is kind of nice because I think it's now kind of bringing the manifesto, but okay, again, manifesto is a bit more in my mind, right? Thinking more of an abstract kind of conceptual thing that we need to achieve. We need to have systems that are all those four like kind of principles, but how do we actually make it happen? So it gets into reactive principles in our design, which, you know, it's kind of nice that saying that I think we need to stay responsive. However, that's, I think that's where I feel that maybe the word responsive, if you go deeper, right, is beyond just the word itself, it can also mean is it responsive for data that's in at rest? Is it data in motion or in transit or is it data in use, right? So there are different state of data too that we need to be worrying about responsiveness. So I think there's some kind of, you know, kind of a deeper kind of, you know, kind of what you call like, you know, defining the word responsive in there. So I think with reactive systems too is basically dealing with, you know, data in all states and being very responsive is my understanding. Anyway, then of course too, we need to accept uncertainty and then with reactive way of doing things is asynchronous by nature. That's very much like decoupling the space and time, right? So very, you know, so there can be things uncertain too. There could be network failures that we cannot assume network is always up that type of stuff. And, you know, uncertainty failure and then assert the autonomy and tailor consistency of these things that are still kind of high level. But I kind of like the fact that we really are decoupling the space and the time too. So you make, you know, your style of programming or design, everything is very asynchronous in nature and also handle dynamics. So over there too, as we know, it's kind of like the diagram that we describe the manifesto in there. So, okay, so that's reactive. Now the thing is too, as I'm kind of working more with events streaming these days and nobody talked about reactive, but I kind of tried to draw some comparison between, you know, these two camps of thoughts, right? So I call it like the alphabet soup of event computing. As we know these days, events, you know, and, you know, it's been kind of overloaded in the marketplace. The marketing team like to use that as a way of attracting attention. And certainly it has a track a lot of attention too. And I go to speak at conferences, a lot of people may be curious, but the actual number of people actually using event driven systems or using, you know, asynchronous style of messaging are not that many for some reason. People are probably more curious than they are actually doing things. But anyway, so I kind of decided to look into all the terms, right? So they're like, you know, essentially too, there's event, if you talk about events, you know, I kind of not highlighting those in here, event sourcing, event driven architecture, event processing, event streaming, event messaging, all of these, and essentially too for events, right? And if I look into like the basic definition of an event, you know, breaking it down like an atom too, it's basically an occurrence in space and also time. So think of like XYZ coordinate, if you need to represent an event, right? And then, and it also has a time component to it. But the difference is that we don't like use one, one way of capturing the state, state changes. Essentially, we want to capture each, well, okay, so that way, that way, events basically are kind of finite too. So an event occur so you cannot change it. It's kind of immutable at that point. And then you are changing the state changes of that event, as the data kind of travels through time. So the thing is too, at the core of it too, is that event messaging, event streaming, processing, all of these are dealing with data. And especially in today's world, this massive amount of data too, can be, you know, mostly too, are kind of events are data, mostly like in motion or in use, rather than at rest, like, you know, maybe reactive systems, maybe also working with data at rest, because you need to be doing some sort of processing to data that's in a database or storage like that. But anyway, so that's just, at least in my mind, that's what I'm looking at it too. And also too, I've highlighted a couple of things too that I feel reactive systems are already kind of employing this react event driven kind of way of doing things. You know, it doesn't say it out loud, but it is actually using event driven way of doing things asynchronous, perhaps like messaging can be using pops up way of doing things, right, and doing message queuing, depending on your, you know, your, your usages of these things. But ultimately too, they are also talking about building data pipelines too that are, you know, highly, you know, you can kind of stream data, like ongoing delivery of data, really fast and everything like that. So that's reactive systems. And then of course too, it gets into serverless applications to serverless to by nature too, it's already using kind of an event driven type of approach and, and can also be kind of applied to like reactive systems as well for serverless type of applications or at least this is how it's being defined in the field. And then there's also like microservices too as Hugh also brought up, right, these days we're all talking about microservices and then the nature of microservices so decoupled in nature and also like ideal for cloud native environment stateless is the way to go. But you can also support like stateful microservices as well. So all of these two are kind of, you know, all, all these are really about event computing reactive is also so, but I think that if reactive definition is kind of higher level of abstraction, that is kind of not just about the event event may be kind of working more with, you know, the mechanism of messaging of streaming processing all of these, whereas reactive is probably like a higher level that you have all these goals you need to achieve as it's more abstracting out what is needed. Okay, so basically too, if I kind of look through all of these, I find that, you know, these are like just some of the goals, right, where we're talking about apps that needs to be responsive, right, it can be, it also should be real time too, especially in event streaming cases. The real time is actually the goal of such to everything, you know, not quite exactly real time, but it, you know, strictly speaking is basically near real time is what we're looking at. And then also too, they are both to event streaming in today's world event messaging all of these and reactive, they also are, you know, targeting targeted in this cloud native environment that that is like so, you know, kind of so important too, because in any any kind of cloud native environment, you are being charged, you know, by the by your usage. So you want to make sure that it is very efficient is what it is. So and also the aspect of recoverability from failure as well. So it's kind of their resiliency should also be built in. And then also to very asynchronous, the messaging and processing part, there's no time that we can, you know, allow it to be wasted, basically. And also to one aspect of using event streaming or event way of doing things are essentially and with reactive systems is that you can actually enable your, you know, your data to be built as data pipelines to our system. So you have data that flow flows through different systems and then you can use different languages to implement your flow of your system of your data through the system as well. So ultimately too, I think it is what it is, is that event streaming event computing reactive systems are basically we want to make a system that's resemble how the human brains work. How do we interact with people? We don't, you know, when we do things, right, we, we, we would be always doing things in asynchronous manner. Nobody is doing things like synchronous, right? If you're talking on the phone nowadays, you want to talk and both can be talking at the same time. All of these is a way of kind of, you know, kind of a resembling what real, real life should be like that. So, so that's how like we then even driven approach reactive systems are enabling us computers to work closer to how human beings think. But I guess unfortunately too, what I'm finding is because the way we've been taught, you know, in school, when I first started school, we're being taught to program in synchronous style blocking fashion. You're, you have a request, you send the request to your processor, it come, you have to wait for it. And then when it's done, then it sends back the response back to you. So that's, I think that's how our minds have been trained because that's probably the easier way to do when we first learn about computers rather than thinking of things asynchronously. But I think that's the thing is that we are trying to do systems that are more asynchronous these days. So, yeah. So ultimately too, having, you know, systems that are more resembling real, real human interactions is that you're bringing it, bringing it more like status satisfactory in, you know, customer experience and more effective applications too. Okay. Okay. So then this is just what I'm kind of thinking in my mind is that we have the event streaming all of these event kind of things and they kind of comes together essentially trying to wear what we're trying to do is build better systems that resemble how the human, human beings do things. So that's how this, okay. So, but I like to, before I go to just want to think of some challenges too, right? Right now, as I'm finding, right? I mentioned about, I go to talks and finding there are lots of people with lots of interests, but only usually to it, every conferences, you have a few people that know the systems very well and they come, come out with difficult questions. Those are really valid questions. But the majority of folks too are still kind of asking or learning about it. So I find that maybe, you know, because of this paradigm shift that's needed for us to learn, so perhaps too, we can think more about how can we make these systems to be more approachable by, you know, more folks if possible, right? And also too, because business too are not willing, they're usually impatient and, you know, with kind of anything that's more difficult, it takes more time to, you know, to be educated in order to know how to do things. So that type of stuff. So can we kind of make the tooling a little better? Maybe. And kind of make it easier for people to use. How can we design tooling to kind of serve people better? Basically. And also too, some of the other things I like to kind of think about is we want to kind of build in, you know, guaranteeing security of message delivery. That's also very important and also like easier to debugging and observability kind of aspect too. And then we can actually do some like education on the grass root level too. Maybe to schools to start teaching kids through to think, you know, asynchronously, maybe we can increase the adoption eventually. Like, so it makes it more mainstream thinking rather than people coming out and learn things the old way, then it's harder for you to switch to the new way. So that's that. Okay. So before I go to just thought I kind of share with you because I was at a couple of conferences was kind of talking with some folks and this one too. I think it's a prime example as to why we need to definitely advocate for event driven systems, event streaming and reactive systems. I was actually talking to an architect of a major pharmaceutical company here in the Midwest and he was describing to me this problem they are trying to solve. And I think, you know, he was talking about some of the problems about, you know, you don't want to be waking up in the middle of the night to fix things. If you can do things more event driven, it's actually easier for your life. But this particular example of the pharmaceutical company is that they are trying to do, okay, they're selling pharmacists or medicine, right, to end users, but or consumers. But the thing is too is that, you know, they are going to always going to, let's say, a CVS or a Walgreens kind of, you know, middleman. So they have been only doing B2B type of business, but now they want to get into B2C, so directly to the consumer. So take for example, if you're, you know, you get medicine for a diabetes patient. And the thing is we want to maybe have devices of measuring the blood level sugar of the patient that's taking the medicine and if it drops, right, you want to be able to have it notify somewhere that maybe, you know, your pharmaceutical company, they want to keep track of all of these use cases. And so if there's a drop in your, you know, blood sugar level, you want to notify, maybe you want to notify not only, well, the patient itself may not know himself or herself, but you want to notify maybe like their family, somebody close to their, you know, or some legal guardian or something to notify them. So then they can take action on, you know, kind of telling the patient, please take your medicine, you forgot about your medicine, something like that. So I think it's really exciting is that event-driven kind of approach can be applied to so many creative different ways that you can actually improve human life. And in this particular case with a diabetes patient or any kind of patient they're taking medicine, you use this kind of system of being able to measure somebody's health and then being able to notify anybody that are taking care of this person. So then the life, you know, maybe, you know, not be ending too short, it's kind of like that. So anyway, so that's just an example of what I think this, you know, is just an exciting field that can be applied to so many creative ways that can enhance our lives and not only enhance, but really save lives too in some cases. So I think then with that, let me kind of go into here. I just want to say thank you again. If you want to stay in touch with me, these are my LinkedIn and Twitter handle. And also I have a Discord server too, where I actually answer questions, but I actually have a Twitch channel too. But if you come to my talk, I'll share that with you. But otherwise too, I've been doing a lot of different things in my Twitch, so you're welcome to join me. So with that, thank you so much. And everybody, please enjoy the conference. And thank you so much again to LightBand, to Hue, to everyone giving me this opportunity to share with you. Thanks.