Transcript
Hi Mike Matchett with Small World Big Data. We are here today talking about event sourcing. Event sourcing. You might be asking what that is. It's a way to really make your applications and development and your code and all your business processes tell a story that you can interact with. That's my take on it. We're going to get a more professional take on it with Axoniqs. So just hold on a second. We'll get right down to it. So welcome, Jessica. Welcome, Allard, how are you? How are you doing today? Great. Thanks for having us. Thank you. All right. So, uh, one of you one of you runs this business and the other one made this business. Just tell us a little bit about, uh, you know, how you got started. Maybe we'll start with you, Jessica, where, you know, how did you get involved in this end of things? Uh, event sourcing, it seems. It seems very system energy? Yes. For sure. And what drew me here was open source. So prior to Axoniq, I was the COO at Anaconda for eight years or so. Um, which I saw the power of open source and the innovation that it brings and thought, you know, this is a great opportunity. It's actually very similar size and stage of when I joined Anaconda. Um, and then I grew that to unicorn level and exited, um, there. So with that said, I was like, let's make unicorn number two and um, excited about it. I think that also Axoniq has a very unique kind of point in time with AI. It's almost like we were preparing for AI for the last decade and our time has come. We've been solving native AI problems before AI was even kind of mainstream. So very excited about all of the capabilities that we're bringing to market, that a large team is building and excited to dive in. All right. Uh, and, uh, Allard, you were foundational in what some a lot of people, especially in the larger enterprises, know as axon. Uh, the axon framework. Uh, how did you get started doing open source and creating event sourcing? I don't know, was it 17 years now? Yeah, it started 17 years ago. And I happened to, uh, to work for a small consultancy firm that was involved a lot in the spring framework. So open source was already kind of natural in that, in that organization. And I started to explore different ways of building software and that that turned into axon, that little experiment, uh, turned into, into axon framework. And because open source was just the way we did things. Um, yeah, the framework was, uh, was open source. And I think that is a very, has been a very important aspect to the success of the framework. And, and now as a company, we're trying to, uh, turn that success into also a commercial success. All right. So I think the audience at this point is probably going, all right, you're talking about event sourcing. Maybe someone should explain that to us a little bit. Uh, let's, let's just get the high level view of what event sourcing is, uh, for people who might not know. Let's catch them up. From a very high level business level view. I explain it as kind of the infrastructure that understands the who, what, why, when all of kind of the most important elements of what's going on in your application and a, does it in a way that orchestrates it across distributed systems and puts it all in one glass box, if you will, that tells that amazing story and then feeds that story to different systems, different users, whether that's AI or humans. And it's a single source of truth that's very important in governance, but also in true, accurate, meaningful AI. I probably are very much oversimplifying it, so I'd love to hear a large technical version. Yeah, maybe you could take us down just a little, little bit. And, you know, I think there's a lot of people who are comfortable with, you know, what logs are, what audit trails are, what, you know, ways of making, you know, instrumenting code to do things are, but we're talking something that's, that's, that's up leveled a bit. They're talking something where it almost seems like it's communicating with us. What, what is what is that? How did how did, how should we think about that? And, and I think that the story analogy works works best. I always say that every, every system you have, every component you have in that system will tell you a story, right? Your current database, if you do a SQL query, it will, it will tell you some form of story. But that story has a lot of gaps in it, right? It doesn't give you the full history of things. It just gives you parts of a story. If there's a canceled flag next to an order in an order table, you know the order is canceled, but it doesn't really tell you everything that led up to that cancellation anymore. Sure. Because that's gone. Then you have application logs, they tell you another story. But that's a very technical story. So it's difficult to to recover the the business story, if you will, from that. You have API calls. If you use a message broker like a Kafka is pretty, uh, pretty common in a lot of places. The messages that go over those brokers, they will tell you a story, but they're all fragmented little stories that are, that are all their own version of the truth, but they're not the truth, right? So that single source of truth that that Jess mentioned is very important. And you can only really have a single source of truth if you can rely on that truth to be, well, the truth, the whole truth and nothing but the truth, right? Which is, which is extremely important, then this is what event sourcing does. Event sourcing says, basically it says you're not allowed to make any modifications to your system except by appending an event to a log. And that event is a, um, well, it's a good practice. You can make them technical if you want to, but in an ideal world, there are business events. So what happened in your business? And you put that event in the log. And as a result of that, it gets processed and then changed into the database table still exists, but it is updated as a result of that event being appended. So it's almost the, um, the, a magic diary. But instead of writing in your diary how your day went, you write in your diary as your day progresses and you want to do something first you have to write. I'm going to the grocery store to be able to go to the grocery store. And well, in real life that's kind of difficult. But fortunately in software, that is a lot easier. And that gives you the guarantee that your event log, if you will, we call it the event store, um, contains the, the the whole truth. Everything is in there. Uh, and maybe you could tell us a little bit about, you know, what, what you're doing now, uh, to expose the value of having an event store like, like what, what, what are those layered up things that you're doing that people should pay attention to because, because things like AI and we'll talk about AI in a minute, but let's put that aside for a minute. So I think thematically, two things come to mind. Well, three things really. One is lowering the barrier of entry for folks. So historically, it's your top 1% of very seasoned advanced Java architects, right? So it's really lowering that barrier where its developers and even non developers that want to understand what's going on in the source of truth of their application set. So that's one thing. Um, the second thing that we need to do and all of these are kind of combined is making it super simple and easy. So removing not only lowering the boundary, but lowering the barrier, but also the friction level of that, right? So very easy, for example, in our insights agent, it's human language of why did X, Y, z thing happen and then exposing that causality in human language as well. So your CFO, your product manager doesn't have to then go, you know, put a ticket into your engineering department to go to go chase it. Um, and then thirdly, I think, and most importantly, is really meeting users and companies of where they are. Um, so I think historically it's been event sourcing is so cool. And yes, it's fringe and it's niche. It's a different paradigm of thinking. And we've had this aha moment of maybe that's scary, right? Of maybe we need to be more approachable in the way of. You have a legacy system that's decades and decades old where that team is long gone, but you need help and you need the benefit of event sourcing. Well, not let's not lead with, hey, you have to event source, let's lead with tooling. And we call it the Axoniq discover agent, where we then can run our engine against your legacy systems and then surface up the. The truth is what we see it. There's always human in the loop to help validate, correct, etc. and then we help you along that journey. Um, so those are kind of the three main points and obviously all of which really weave into AI explainability and helping distributed systems along the way. Uh, so, so, so what does this, what does this look like to an application adoption? A developer who needs to adopt this? Like what is, what does it take to add eventing or what however you call it? I don't say vent storing. Venting. Venting. I use as well. Yeah. Okay. I like it venting. What does it take to add venting to to some of their core business processes? Yeah. So that's, um, it depends. Right. Which is the, uh, the, the one and only answer to all sorts of questions. I hate it when Allard says that. And so do I, but it's the only correct answer. And I'm an engineer, so it has to be a correct answer. Um but um the um so what it takes does depend on what you try to achieve. So to, to get to this point where you have the full truth of everything, you really have to take events as the source of everything, right? It starts with an event, um, that hence the word event sourcing. But um, to get from, from a legacy application to event sourcing is a long journey. So there's definitely, uh, the worst thing you can do is, oh, look at the old application, build something completely new. Now consider it a green field and replace it. Replace everything at once. That is definitely not what you. What you should do, what you can do it. If. It's a small, small system. But generally people do it slice by slice. And those can be vertical slices where you say, you know what, we're going to take one piece of functionality because this is a core piece or a piece that we see generating a lot of value. There's value in, in capturing the entire story of that piece of functionality. It could be, for example, the checkout in a, in a, in a retail system. Um, and, and you can say, okay, let's start with that small part. And then we build that part event sourced, we connect everything to, to the existing system. And then as we, as we get the value from that, we do the next part. This is what one of the, the bigger grocery stores here in, in Texas, uh, recently did. Um, and then, but another way could also be, okay, let's, let's start horizontally. Let's start with emitting events. Let's, let's identify places where our system does something that we think, hey, this is worth remembering. So we can just start emitting events. So we're not doing event sourcing, we're just producing events and keeping them for for future use, which, which could also have a benefit. And this is something you can do across an entire application because it is very non-disruptive. Um, so whichever approach fits best and maybe it's a combination of the, of the, of the two. And this is what our discovery agent will, uh, will help resolve. So it inspects your current code base and it will give you suggestions of, of which areas are relatively independent and can be taken off as, as slices, which area should be taken horizontally by producing events instead. All right, so you've got some, you've got some um, tooling now that helps someone understand where they should actually dig in, what they should tackle next. Uh, and to get higher level values out of this, let's, I, we don't have a ton of time here. And this is a huge topic, but let's talk a little bit about AI and the timeliness of doing event sourcing. Now that we have eyes that can also hold up kind of a conversation on their end, it seems like a really good match, a really good time frame to make your code basically tell a, you know, create a diary, tell a story of what it's doing, why it's doing it when it's doing it, uh, as opposed to just emitting logs. Right now, we actually have some rationale. We have some, we have some, some ways to deconstruct and go back and figure out what it was doing. Um, and then we have AI now that people are trying to do automated things that can actually hold up another kind of conversation from the outside into that system and do all sorts of things. How do you guys see that coming together? What, what, what do you see as the biggest opportunities there? There are so many opportunities. Where to start? Um, I think with AI, for me, it's kind of twofold in that because of event story, having that immutable diary log in your unique business logic that pairs really well to the governance aspect, which isn't a choice. I mean, the EU AI act, and the second phase of that rolls out in August in a couple of months, where it requires not just EU headquartered companies, um, but AI workflows that are touching EU data and consumers, which is every global company today, um, requires that explainability log, which we have built in natively, not just as a bolt on. So I think that governance and traceability aspect that really is, I frame it as trust in AI, right? So I think one angle is the trust. The second angle for me is just better AI. So I would trust an AI output much more if I knew it was training on the full, you know, a large diary versus what a large is feeling like today and only today. Um, so I think it's twofold from a business aspect. Okay. Okay. Uh, and, and how, how would, how would someone start to think, you know, if they've got AI initiatives and they've got people saying, hey, we need to use our AI to do things. We've got AI coders out there. How's this going to merge or meld with those kinds of trends that are going on in, say, an application development group? Yeah. So that's a very interesting, uh, aspect of, of accidentally, I guess, how the, how the framework requires developers to, to structure their code. And it is very much around functional slices. So the, the slices I was talking about earlier, right? The, the checkout, well, checkout is too, too wide of a slice. It's actually a lot thinner than that. Every little action that you do is very well defined in axon framework or Axoniq framework on how to do that, how to structure this. Um, and you can instruct an AI very easily, uh, to, uh, to follow that structure. And that gives the coding agent very strict boundaries of what you expect it to do. And it also gives it a very limited scope of where it needs to make changes. And we all know that coding agents are really good if their context window is small, if they need very little information to, to do it, um, then you get really good results. But as soon as you start, let's say the traditional vibe coding when it starts, oh, I need to do this in the UI and that in the database. And this there, it's, it's generating so much context that at some point it's actually losing track of what it was doing. And it starts to make very subtle, uh, mistakes and it starts correcting itself, but doesn't fully delete everything that it did. So it doesn't undo everything. And it, it tends to forget, um, very human like almost, but, um, with, with, with axon framework that doesn't need to happen. You have very strict functional slices. Okay, this is what I need to work on and I can validate that that slice. I have certain rules. Um, we call them given when then tests. Right. They're again, they're very business, uh, language oriented, given I have canceled an order and I can try to cancel an order, it refuses to do that given. Well. Et cetera. Et cetera. So you can the AI can can build the test. The AI can write the code, can validate its own code. And when it's done, it's done. And we can move to the next slice. We clear the context window and we start over. So we see that, uh, teams that adopt this, uh, this AI driven development, um, I'm not coining a term I hope, um, uh, approach. Um, they have a lot of benefits in action and we see our customers that have adopted the AI developments because we, we have large enterprises that have some internal challenges doing that. But the smaller companies, they tend to do that a lot faster. They are moving very, very fast. All right. So we've got we've got the use of AI within the effort of event sourcing and doing a better job there and doing that. We've got certainly the opportunity for AI externally to the business process to communicate better with that business process to do, as you pointed out, Jessica, governance. I can also imagine, and I think we might have talked about this, uh, a couple of months ago, that if you do event this event store properly, you can do things like, um, all sorts of system management tasks. You do capacity, uh, performance optimization of your infrastructure. You can help it scale, you can help it, uh, you know, visualize the patterns of usage. So you've got this help you evolve your infrastructure and your architecture, even your deployment, like, should things go into the cloud? Should things stay on premise? Um, certainly troubleshoot, identify problems and certainly a much better audit trail than a log file, right? Because now you've actually got a diary and a story of what it was doing. But I think there's even this bigger thing around this yet that maybe we haven't really understood or concept. But I see it out there where AI by an enterprise that's doing business with with their AI efforts. Now that that AI under the hood can interact with all the other business processes that came before because they're also communicating. So in a way, this becomes a kind of way to create a communication layer between things you already have hard coded and the things that the new generations of AI are going to try to automate for us with agent swarms and the rest of it. So I think there's even more coming at a bigger level. Um, but that's all the time we have today to talk about this. Sorry, there's more. Um, there is more, so much more. I was going to say that is exactly the workflow launch. So check out the workflow launch and that that really helps kind of orchestrate to your point, systems agents, etc.. Um, again, in human language, context, business contacts into the event source. So check that out. All right, so workflow agent I was going to ask, so just as we close here, what should people walk away from here who are interested. Look at next. Obviously there's the axon framework as an open source piece. But if they want to like maybe dig into like what you just mentioned, workflow or each of you, which what would you point them at from both a sort of a more business perspective and a technical perspective. Um, I would say go to the website Axoniq.io as a good starting point that shows all of our product portfolio and shows you really, and we, this has become a mantra that a client of ours says, I want to get the benefit of event sourcing without event sourcing, because historically it has been complex, right? And fringe. So if you go to our website, hopefully that really distills it down and up levels. The message of I now have tools to be able to do that and meet you where you're at, whether it's I want to go straight into the code with framework, or if I want to take a step back and really do more of the workflow element, or if I just want a prompt and kind of vibe code, we have the development agent. So there's so much there to dig into. So go to the website. The website. All right. Uh, and that's all I got today. Time today for, uh, we want to have you back maybe and give us a demo of some of this at some point, because I think that would really hit home what an event store is going to do for people and just how it's going to, uh, really open up their ability to leverage whatever AI things they're doing elsewhere in their enterprise. Right? Just, I just see this as a huge opportunity. So come on back. Otherwise, thank you guys for being here today. Thank you Jessica. Thank you Allard. Thanks. We appreciate it. Thanks for having us.
