Okay, I don't know what we call this. I think, oh, special session. This is a special session. Welcome to the special session. I'm Michael Turits, enterprise software senior research analyst here at KeyBanc. It's a, it's a fun and special session. We're here to talk about Confluent and data streaming and Apache Kafka. We have with us today, Jay Kreps, immediately to my left. Jay is the CEO and cofounder of Confluent, ticker CFLT. We have coverage that, we were on the IPO here at KeyBanc. Jay will tell you a little bit about his background, but he was formerly at LinkedIn, where he was an original author of the project called Apache Kafka. And then, as, as I said, founder of Confluent. In addition to that, of course, we now have with us KeyBanc's Chief Data Officer, Mike Onders, immediately to his left, and then Scott Tucker, you just told me what to call you by role, but you got it, Senior Business Technology Executive, open banking. There we go. Head of Kafka and Messaging Technology. We can add some more words in there if you want. Yeah. Uh, just- He's, he's our, he's our hands-on Kafka guy. I like the fact that it's open bank. Maybe we can talk a little bit about that. In any case, thank you, thank you all very much for, for being here. I, I wanna, I wanna start. The, the idea is here, you know, twofold. One is, for Jay to tell you a little bit about the, you know, where, you know, why it was that, that Kafka came into being, how he brought it there, how he sees the vision for, for Kafka and for Confluent more, more broadly. You know, to talk about how we're implementing Kafka and Confluent here at, at KeyBanc. We'll, we'll start with you, Jay, and I would say, let's do that. Let's give us an overview of Kafka. By the way, I forget exactly where the name came from, but some of you, I, I hid this for years, but I do actually have a PhD in comparative literature. Kafka was a writer, thanks for doing that. Well-placed with this one. It's perfect. It's perfect. You've got to have your existential- existential, there we go. Uh. A more optimistic view. Kafka is a little dark, but I think- That, that's right. That's right. Well, yeah, so you know, as, as you kind of hinted, I was at LinkedIn, and that's where this open source project was originally created. The idea was to focus on data in motion, so, like, you know, what does that mean? Well, like most data technology had really been oriented around: How do I store a little pile of data? How do I look up the right bits at the right time for one application? That's kind of the hallmark of databases. A ton of incredible research went into that. You know, that was a very sophisticated platform, but if you looked at, you know, an organization like LinkedIn, it wasn't like we had one database. We had, you know, hundreds of databases and hundreds of applications that all had to kind of come together into one company and service and set of products. Just for framing. When was it you started at LinkedIn? Yeah. What, what year, what were you starting to think about? Yeah, I, I was there from about 2007, and I was involved in a lot of the, you know, next generation infrastructure, analytics, kind of machine learning use cases. I was actually brought in to kind of help use the data, but then ended up more in the infrastructure layer because, you know, that was kind of the first step to really being able to harness it. Yeah, a lot of the early work I did was on scaling databases there. One of the things I realized right away was, hey, if we want to take advantage of the data we have, it's not just about scaling this application or that application, it's about how it actually comes together. How does data flow between things? How can we act on the data we have? Can I throw the real-time buzzword in there? You can throw the, the real-time buzzword. Okay, real time. Yeah. Real time. Yeah, yeah. There was one fact that was really weird to me, which was, at the end of the day, we would pull data out of all these systems, and we would ship it to, like, this, what we would now call a data lake and data warehouse, and then we would run this batch processing on it, and we would come up with some results, some of which we would try and feed back into this product. It was really hard to do that, because if you think about it, the customers who were there at the time, who generated that data, they may not be back the next day. You've kind of done all this processing, and they're not even there for it. It didn't really make sense. We had this business that kind of operated all the time in real time, a lot of the processing technology, the most sophisticated use of data, was not and could not be because of technological limitations. If you think about it, that's kind of how all companies are. Pretty much all of them work here in reality, in real time, continuously. They do now. They probably didn't at one point. Yeah, no, I, well, you know, I, I think even humans work continuously in real time. It's this weird outgrowth of mainframe technology that's this kind of batch processing mindset, and it, it's taken a while to shed it because there's a lot of technological complexity to doing that well. That's what's happened with the rise of Kafka, and a lot of this streaming, is the ability to think about data as something that's always evolving and happening, and think about the processing as something that happens with it. You know, early on, this was an internal layer in LinkedIn. We released it as open source to really resounding... This was around when, roughly? I think it was probably around 2011, 2012. You know, really to resounding silence, because nobody had any idea. That's not exciting. Yeah. We thought it was gonna be like the, you know, the, the, the next best thing since sliced bread. Nobody knew what we were talking about, but we spent some time talking to some of the other tech companies, and this became really the kind of foundational layer for all the flow of data and the harnessing of data in that kind of next generation of tech companies, the, you know, Ubers and Airbnbs and Netflixes. You know, as this kind of movement around streaming started to grow, we realized, You know, this isn't unique to tech companies. You know, actually, in many ways, harnessing data is even more important and more challenging in some of the larger enterprises, where they have more software systems, more investments, you know, more lines of business, more basically diversity and sprawl that they have to put back together. The pressure on them is very much the same, to, to have, you know, a digital side of the business that interacts with customers, to be able to operate more efficiently. That was when we left to start Confluent, and really kind of take it out to the broad market, and that was in 2014. Let me ask you two questions then. What is it? Is there something about... This one is a very geeky question, maybe one's more of a business question. There's something about what we, what we think of, of as cloud-native architectures or modern architectures, that requires this real-time data treatment that Kafka enables, A, and then, B, from a customer perspective, like end customer, like, and we'll get to, obviously, KeyBank's customers, what is it in the way, what we're looking for that requires this kind of real-time data? An architectural question, and then jump right over to a, a customer, end user perspective. Yeah. Yeah, architecturally, you know, this definitely is an important layer in a lot of the microservices architectures, which internally is kind of the more modern thing people tend to build towards, and it helps to plug together lots of disparate applications. You don't necessarily need that to take advantage of it. You know, even organizations which have no microservices have lots of different systems with data that need to come together. Yeah, you know, in a, in a sense, one of the interesting things for Confluent that's maybe different from a lot of tech companies is, we tend to not be coming to customers and telling them to, you know, "Hey, rip out everything and rewrite it with us." You know, very much our story is about connecting some of the older things, you know, the mainframes, relational databases, things that have important data that run big parts of the business, and connect that out into some of the newer applications that are driving next-gen customer experience or doing some of the new initiatives that require new software. Really being able to connect that together is an important part of what we do. Then, you know, for customers, yeah, that, that's very much the goal, is being able to bridge all that, do it in real time, being able to bridge between on-premise systems and cloud systems, being able to bridge between old and new, and being able to, you know, really bring to bear the data that companies have in the right way, you know, at the right time, to try and make their business better, you know, serve their customers better, be more efficient, all of those things. I, I guess where I was leading is just like me, as like. Yeah, yeah. someone going online, what do I need as a customer these days? Yeah. -in terms of my customer experience, that says, "Man, you've got to have something like Kafka delivering this on the back end? Yeah. Yeah. Well, you would experience this all the time when you don't have it, right? You show up to any organization or company that you work with, and you expect the interaction to have full context on what you do with them. What kind of a customer are you? Which parts of that business do you interact with? What is it that might be relevant that you need to know? What is not relevant? When you don't get that, when you get things that are out of sync, that aren't in line with what you would expect, you're kind of frustrated. Right. It just doesn't seem like a modern digital customer experience. I hope Newark Airport and United Airlines as a customer- Yeah. because my experience in the last month tells me that they're not doing this. Yeah. Yeah. You know, I would say that, that, that's actually an area that's definitely started to invest in this area and really needs it. You know, these are industries that are older. I mean, seriously- And- I'm gonna again, love United, big big, you know, user, but, you know, this has been a terrible couple of months for air travel, and I was in the airport. I'm sure some of you had this experience, but what was on the board. Yeah. - what was on- Yeah. What was on my phone. Yeah. What I was getting from customer service, were all three things. My flight that had been canceled the night before was listed as boarding. In any case. Yeah. Yeah, it's a perfect example of an industry that is extremely real time. It's all about flights and, you know, the dispatching of baggage, passengers, what's available, what's not available. It's all very real time, but it was all built on very old technology a long time ago, and it doesn't quite work as well as you would expect it to for something in the modern world. Indeed, that investment is happening, and I, I think it significantly improves the customer experience, and it significantly improves their operations, because when they don't know what's available, they end up, you know, padding out. You have to have extra... This happens in retail, where you end up with extra inventory. It ends up in travel, where maybe you end up with unsold seats. You know, it happens across the board, where you're not really reacting to the full set of information you have, or you're not reacting quickly to what's happening. Last question, before I move over to our guys here. Open source. Yeah. Kafka is an Apache open-source project. You started Confluent. This is a, a, a big, big question, this whole question of monetizing, commercializing open source. I don't know, I mean, a couple of things I, I can remember, my, my son is 23 and a software engineer, but I remember when I was rolling out Red Hat years ago and tried to explain to him, because he was curious, how people could make money selling free software. Yeah. I feel like I explained it to him, but there's lots of different ways to do that. sometimes it makes sense, some-sometimes it doesn't. For example, we, we don't really actually have that many Kubernetes companies out there at the moment. That's right. That's right. We, we do now have an important company in Confluent, selling Apache and monetizing Apache Kafka and broader capabilities. What is it about Apache Kafka that you looked at it and said, "Hey, you know, good, did it, open source. No, I can build a company around this? Yeah. Why can you add value around this project and around associated types of technologies? Yeah. You know, certainly as we were getting started, you know, I think there was a lot of people who didn't believe that open source companies were very viable, but there was really an evolution of these models. If you look at what a company like Confluent does, it's very different from Red Hat. We're not selling, you know, support services around the open source. You know, we really have a very differentiated piece of software that we license, and we have a cloud service, which is amazing and world-class. You know, those are really significant investments in proprietary technology, which allow us to have an edge and just be much better in terms of TCO, than you would be with the open source, much better in terms of the feature set and experience. Then that value proposition becomes very compelling because, you know, this is something where maybe your, the, you know, the open-source software could be free, but you're gonna spend a lot on cloud infrastructure, on people. You know, the advantage of these managed cloud services is to roll up all of that and then take away the whole problem and just do it well and say, "Hey, we're gonna come in. We're gonna make sure that you have world-class operations at scale. We're gonna make it so that you can just elastically consume what you need. By the way, we're gonna bring to bear a product experience that's 100 times better than what you would have with some internal infrastructure offering." That's, that's actually really compelling to customers. You know, that often customers feel like they're kind of at the mercy of these infrastructure layers. They can only move as fast as their infrastructure teams. Getting something like that allows customers to really move quickly, and I think that's what's really been a tailwind for, you know, us as a business and for all these next-generation technology layers. Yeah. Okay, let's, let's flip over to KeyBank. Again, Mike and, and Scott, maybe you can... You know, I, I wrote this question up, and I said: Can you describe our history with both Kafka open source and with Confluent? I think we, we, we did come to them both at about the same time, right? I don't think we were ever-- were we ever, purely open source on Kafka? We did have one use case to start that was open source before we got engaged with Confluent. It was around log aggregation. We, we did that. Gathering those logs, enriching the data, and then putting them in Logstash. We were, we were using it for that, but our, our first real use case, you know, across the bank, was with Confluent. All right. So, so let's why don't you, I don't know, do you want to handle it, Scott, or you want to handle it, Mike? Talk about our, our history, therefore, with, you know, starting from that, with both with Kafka as open source and with Confluent. You know, we didn't really touch on this when we were talking a minute ago, Jay, but why we decided that Kafka was important as opposed to older, let's call it, legacy messaging architectures. Because like, like MQ messaging, there were, there were plenty of others going all the way back to what we used to call, you know, message-oriented middleware, you know, back to TIBCO and further back to webMethods and all this kind of stuff. What was it in terms that we thought that we needed to see in Kafka that was important to us, even though we had some of these other capabilities? All right. A lot of it is around, so there's legacy technologies, whether it's MQ, whether it's ETL batch, right? They serve specific purposes for us. A lot of it is point to point. What we were seeing in our business is a bigger need to get events across the organization that you would then react to in different ways. As a simple example, somebody opens an account, we both want to be able to communicate to them via email notification or text message, as well as update some of our internal systems to be ready for them to onboard in the online banking, and then maybe send that to our fraud system to make sure that we do the right checks there. There was multiple needs, and instead of having kind of that one-to-one integration that we had with legacy integrations, integration technologies, we decided, hey, this Pub/Sub, this data streaming is more beneficial for us. Let, let's, let's stop there because that's an important differentiation, right? There was real-time messaging going back, I don't know, 30 years, if you will. You, you mentioned Pub/Sub really, really quickly, and, and also, I've said that we get points for saying central nervous system. The, if you, if you... central nervous system, hub nervous system is cooler. In terms of this architecture that Kafka has, it's this differentiated, talk a little bit about this, this Pub/Sub architecture, the centrality of Kafka within it, and why that seemed important versus these other technologies that we have. We have macro. I'll do a little bit of macro and kind of tie into what Jay said, right? As a bank, we have 1,000 applications, 300 of them are already SaaS or ASP, so they're not in our data center. 300 are vendor packages in our data center, and about another 300 are custom. You know, all of our legacy core accounting were mainframe apps, right? MQ was the way to get to the mainframe for the longest period of time with guaranteed messaging. We stuck webMethods in front of that to talk to distributed systems, but then still had to go to MQ. He, he only like, "Hey, if you look at a wire processing, it would go from a wire origination system that was distributed, to webMethods, to MQ, to talk to a mainframe, back to an MQ, back to a webMethods." What's happening, and you talk about customer experience right now, many of you, like, how many of you get alerts by your credit card all the time, right? Especially if your kids are using your credit cards, right, you'll get an alert where they're at, and, and you, you expect that now. I was at a gas station, but I'd use the credit card my entire vacation, but I've stopped at a Flying J, and I get this message saying, "Did you just buy $151 of gas at Flying J?" I hadn't even put the thing in my car yet. Which the, the correct answer was no, I knew if I said no, they'd lock my credit card, I didn't buy $151. The consumers are expecting alerts real-time. Well, our legacy core accounting systems were batch, you're struggling this legacy in real time. Now you've got multiple systems that want that data all at the same time. If you do a transaction, it's got to go to the fraud system, it's got to go to the AML system, it's got to go to an alerting engine because the customer wants to be alerted. It's got to go to the core accounting system. It's got to go to the data supply chain to get registered. Now you've got six, seven, eight systems that all want that same data, the Pub/Sub is better than saying, "Oh, I'm gonna do point to point, an MQ here, and then." The other thing we're finding as core modernization happens, those cores are now getting to be real-time event-based, where, you know, before it was all batch, batch calculations, you got a statement once a month. But now people expect, which is when we started open banking, was our fintechs and our partners want that data real-time, too. Right? They don't want to wait for a month-end statement. They want that data flowing back to their ERP system the same way we want it. It's, it's really sprawling out the, the messaging across many platforms. That's kind of the backdrop. Then, you know, he did own WebMethods and the whole messaging architecture. You start looking at that, and you say, you know, a Kafka architecture is a better way to solve this problem, right? It's also more efficient from a delivery standpoint, right? You build it once, put the messages in Kafka, and then everybody comes and consumes them versus, you know, the point to point where we're building specific integrations with those six or seven systems, right? It makes it a lot more efficient in our delivery and keeps our costs down and moves us forward much faster. We're from a broader perspective, one of the overlays here is that, that we at KeyBank are, are, are moving cloud, and we're moving primarily to, to GCP, to Google Cloud Platform. How is what we do with Kafka and Confluent, how does that fit in with that migration and with our use of things like BigQuery and Google? Yeah, all of our data, we, we started our data migration 2 years ago. We moved Teradata to Google, and we turned off Teradata. Our on-premise data lake will be shut down at the end of this year. All of our data is there, all our analytics. As I mentioned, SaaS vendors are moving all over, so we use Adobe in the cloud. Actimize is going to the cloud, you know? You've got these, everyone moving in different directions, and you still need this messaging architecture to connect this across. You know, if we're going to do real-time Adobe, you know, next best action, they need data real time to know what's the next best action. You got to flow it to there. You're trying to connect multi-cloud to a lot of people, and the complexity is getting harder and harder. You know, before it was all in your data center, all on-prem, that's not, that's not the state of where the industry is going. This interconnect architecture in Pub/Sub, where multiple platforms that might be in multiple locations want that data all at the same time, it's driving that messaging architecture. Did, did we, did we consider any alternatives to Kafka? I mean, there, there are other technologies out there. Google says-- has a Pub/Sub offering. There's a competitor called Redpanda. There is a competitive technology called Pulsar. Did we look at any of these? We did. It was about 3 years ago when we went down this-- started this journey. We did look at all the players at that point in time. Some of them, you know, are, are a little bit more mature now than they were back then. When we really looked at it, what we liked with, with Kafka and with Confluent was, the architecture fit what we, what we needed. There's, there was a lot of excitement and buy-in, a lot of companies using Kafka, the open source, and moving to Confluent. We felt like we were with an industry leader that can help us. The roadmap, we really liked the roadmap of where Jay and team were, were taking the technology. That really kinda got us sunk in to, to, to go there. you know, it's something we, we continuously, as anybody does, you continue to look at, who's out there and who's doing what. I think Jay and team have done a great job, especially with Confluent Cloud, of just continuing to extend the capabilities and make it easier and easier for us. Yeah, Jay brought this up. We are, for all the vendors we work with, moving to them, managing their own software. It's, you know, we don't want to manage the servers. We don't want to manage the security patches. We don't want to manage the hardware, and we want to take advantage of elastic compute because this stuff's going to grow really fast. If, you know, and if you do a merger, you can expand, you know, on a dime. So we're, it's on our roadmap. You know, I think Jay has a slide, I'm going to say this right, where you start off just doing a POC on Kafka, then you start replacing a lot of your core primary messaging. That's where we're at. We're replacing our fraud interconnect with Kafka and some of our onboarding, processing, and eventing, and alerting with Kafka. Then it'll become a mission-critical, business-critical application. We'll move it to the cloud. Eventually, it'll become our central nervous system of the bank. Yeah. So, so let's, you know, I think we've, we've, we've talked about this, some of these issues a little bit, but I'll ask you the question: Why do we pay for Kafka? Why do we pay Confluent? Why do we... You know, you said you started with open source, Apache Kafka. What are the reasons? Where do you see that? And, and at the moment, we're, we're not doing Kafka, we're not doing Confluent Cloud. We're, we're already paying for it, even without- Yeah moving to the cloud. What are the reasons that we were paying for it and are paying for it, even without going to the cloud? Then on top of that, why cloud might be something else that's commercially attractive to us. Yeah. Jay touched on this earlier. It's not just the support of it, right? They didn't just take open source Kafka and say, "We'll support it for you." They've built a lot of capabilities on top of that, that are very specific to Confluent. For example, you know, being able to do replication and handle DR situations and that. They've built the components to help us do that. If we were to go open source and really handle that, we'd have to build all that ourselves. So there's a lot that we found valuable there. Obviously, as a, as a large corporation, having the support of the experts is something we enjoy that comfort as well, right? If we were a much smaller company, you might get away with, we'll just do open source, and if something breaks, it's not that big of a deal. As we continue to make this more and more part of our, our ecosystem, then if bad things happen, it's a bigger impact across our customer base. Having the folks there that are experts, that can help us along the way is great. It's more than just kinda supporting it. They work with us on a weekly basis about our use cases and help us understand what's a good use case, what's not work. They work with our application teams to help them get more integrated into using Kafka. There's a lot of benefit that they provide to us that you just wouldn't get if you were going open source. Actually, let's, that's a good transition. Let's, let's talk use cases. Let's, I should say, you know, what are, you know, from a, you know, really end customer point of view? Well, some, some of it might be more technical, but some of them, I think, really has use cases for, for KeyBank's customers. What, what are the places, where do we start in terms of use cases? What have we added? Where might we go longer term in terms of the use cases? How, how broad could this be in terms of use case deployment at KeyBank? It could get very broad. Where we started with this is, is really around customer and transactional data, things like opening accounts and changes to customer profile, that we're, we're using to drive some of our alerting and, and also internal system updates. We kind of started there. As Mike mentioned, we're now moving into our, our fraud interconnect and, and updating that, which, I mean, a client doesn't necessarily, on a day-to-day basis, see that, but, you know, when a fraud happens and we catch it and, and reach out to them and say, "Hey, this wasn't you, let's, let's help you," they're very, they're very glad that we do that. Those are a couple of areas that, that we've started in. Where we wanna take it is really getting in the customer behavior. Not just transaction, but if we see the behavior of them coming into online banking or going to a, a branch and doing certain activities, then it helps us better understand, you know, what's going on with them and maybe better be able to react to that and, and help them where they need to be helped, as opposed to, you know. We've all had these experiences, right? You call in to get support for, for your- from your bank or from another company, and you get passed around, and no one has the context, and they can't help you. Much better if when they call in, you can say, "Hey, are you calling about this account you were just trying to open? You know, I saw that you were doing this 10 minutes ago or an hour ago. Is this the thing you need help with?" Then we have the context already ready, and we can, we can help them more quickly and get them on their way. I think the other big one, though, because I do run the, the chief data officer, wear a couple of different other hats, but, you know, most of our data, supply chain data analytics, is batch-oriented, moving nightly, you know, through the models and into marts for analytics. That's all moving towards real-time, too. As, as the core systems become real-time and event, you know, we no longer want to have to do batch, full volume batch, delta processing, rather just changing the data on the fly. I think, you know, where Jay is going, you know, with streaming analytics, then that becomes more possible, right? If we're flowing the data on real time, we can analyze it in real time, we can run models in real time, we can detect fraud faster. The faster we detect fraud, the faster we prevent it, the less loss we have in fraud, right? All that stuff is moving in motion. We can do a lot more stuff for the client, you know, and help them out, as well as lower our fraud costs and, and detect that faster, right? A lot of that stuff happens batch, right? AML doesn't happen real time, it happens overnight, most of the time. In the future, where do you think that, you know, future use cases could possibly be, that we haven't explored yet? I think what I said, I think moving all our data to being in motion with analytics being available on that pipe, that's the future, and we've got work to do to get there as well as working with the apps that need to be able to push that data more real time than batch, right? I, I wanted to talk about go-to-market and ask Jay about that in a minute, but, let's take a little bit of a break and see if there are any questions from the audience at this point. It was a fairly technical discussion at this point, but yeah. Yeah, just on that last comment you made about going more to real time and then shut it off beyond the ground. How do you think about your kind of your costs as you go more real time, use more data, and then are you going to have higher consumption bills versus what we're showing now? It depends. I mean, when we run full batch, ETL, that takes a heavy load to run full extracts and then compare last-- this night's extract to last night's extract to get the delta processing to flow through. It's a trade-off of where you're gonna consume that compute, right? And I think, you know, I think you might find it less expensive to stream in real time than to try to move full batch processing and that kind of a model, right? We do some of it today. Certain, certain transactions that hit our core, we-- even though our core only processes at night, we have kind of a shadow database that simulates real time, that gives you a pending transaction, but that stuff will flow to the alert engine. Like, if you say: I want to know if a payment hits my account or if a, a deduction hits it, that'll flow out kind of real time today, even though the batch will process at night and then sync up. I don't know. I, you know, I think it's our trade-off of where the compute's happening. That'd be my, my view. Yeah. How real time is real time? When you talk real time, is that seconds, milliseconds, what about real time? Yeah. I would say it's, it's dependent on the use case. In many use cases, it's, it's in milliseconds, right? Because we can move that fast. There are use cases where the need is only within seconds. That really comes down to a lot, is the, on the consuming side of, of the equation. We'll get the messages there very quickly. It's just how timely do they get consumed, and that's really based off of the systems that are, that are integrating. Mm-hmm. Yeah. What are the one-to-one use cases getting totally replaced? Do they kinda have to go all in on not getting it? That's a, that's a really good question. I don't know that we've, we've thought about, like, as a percentage, how much, but I would say there's, there's a fairly significant amount. Because every time we're, we're looking at building these, you know, traditionally you would have built all of them one-to-one. What we're doing right now is we're trying to replace them in the fraud space and, and, and move forward. I would say, you know, bare minimum, you're talking in the 25%-30%, and that's, that's a conservative low, right? I don't want to oversell and say everything's gonna be replaced by this, but I think where is more important is where we enhance. There may still be one-to-one inter-interactions that happen between systems, but if we also put that same message in the, in the Kafka, now it becomes more available for everybody else. I don't replace that one, but now I've enhanced it to now others can use it as well. Yeah. I was gonna ask even more broadly, like, not just replacing, like, one-to-one messaging, but, you know, what else gets replaced, at KeyBank in terms of the IT stack? You know, is it ETL? Is it database? MQ is in our sites, right? Which is one-to-one messaging. Which is one to one. I think because I think where we see a lot of that MQ is, we know other systems want that same data. Right, that's for sure. I don't know about all ETL, you know, if this, if the source system can support eventing in real time, we would plug it into Kafka rather than run it through a batch ETL process. I think we're seeing more and more of our vendors start to support Kafka connectors, which then helps us. We were working with Actimize, trying or we're working with Dovetail, our wire processing system, trying to talk to Bridger, OFAC checking, and they're both now starting to support Kafka connectors, where before that was a webMethods and MQ kind of messaging. The more the vendors support Kafka, the easier it is for us to plug it into our overall ecosystem, right? Yeah, this is one of the bigger changes happening in the larger ecosystem is, you know, for a long time, there was no technology to do real-time data movement and processing at that kind of scale that could handle work, you know, workloads like ETL. Then there's also not integration since that doesn't exist. So what's happened really in the last few years is spinning that up, where technology gets better, there's more integration, technology gets better, there's more integration. The integration takes place a lot around Kafka because it has. Yeah. -presence. Yeah. I think, you know, I think what we're seeing happen is there were a bunch of fragmented technologies around data movement, right? Messaging systems were these kind of application-to-application, point-to-point, real-time. You know, ETL was this kind of batch-oriented, but, high volume, high processing load, to usually a relational data warehouse, but sometimes something else. You know, there's two or three other categories of application integration. They all had kind of these weird pros and cons, I, yeah, I think the value is exactly what's been described here, of having something where you can kinda publish the data once, have it go to many things, and have it be scalable enough, real-time enough, sophisticated enough in processing, that you can kinda meet the needs broadly of these different use cases not have to resend the same data five times in five ways. Yeah, I mean, the other thing, I mean, this was a real story. Our wire system had an issue, but you traced it, it went from the wire system to webMethods, to MQ, to OFAC, to MQ, to webMethods, back to wire, to red, to notify it, and it wasn't working. Every one of those had their own logs, so you had to chase log by log by log by log, trying to figure out where did it stop and why did it stop? Versus having a single hub site where you could see who, who picked it up, when did they pick it up, when did they put it back, if there was a reply. Like, that architecture, we think, will be significantly streamlined and better to operate than, like, going hop, hop, and hop, and then trying to trace it through multiple logs, right, that weren't connected. I want to bring up, go-to-market. I, I feel like, you know, so, I don't know, say, land and expanding. I love it when companies tell me they have a land and expand model. It's like, "Great, that's wonderful, and that differentiates you," as opposed to, like, not add customers and have the others contracts model. In any case, look, I feel like landing is relatively easy for, for Confluent, Kafka, to the extent that people in technology know about Kafka, they might have one use case. But what... I don't know, Jay, talk to me about how you think about that for Confluent. In other words, how much emphasis do you put on landing? For me, I'm very interested in the expand part of it. Yeah. Yeah. I see those initial use cases, but how, how do you go about helping people say, "Oh, you can do this, and you can do this, and here's how we can enable that? Yeah, that's exactly right. The way we've thought about it is, you know, our goal is to really, at the land stage, get the volume up. There's a lot of open source Kafka. We think we have a great offering that we would love people to start with, with their first experience. You know, our goal is to make that as low friction as possible. So hit those people who have got some Kafka to begin with. Yeah, yeah. It's, you know, we don't need to go take over all the usage of data in the organization, just to serve that one use case as it comes around. Then, you know, as you expand, and this, you know, grows to have a more strategic role in the company, where it's connecting many different teams, you know, you need to have a more senior relationship. You need the people who are plotting out architecture and making decisions across the company to understand what it's good for and what it's not. You need to help guide how that progresses. So, yeah, you know, the, the goal for our team at the low end is make it easier and faster and better to get going. Then, as we go, it's about how can we help guide the customer and make sure that they're successful with this broadly, and it continues to spread and become a really successful data platform for them over time. Yeah. Yeah, maybe that's the same as you would hear for any company, but it's, it's a little bit unique in this streaming area because to some extent, the platform gets more valuable as there's more streams in it. You know, the, the-- because the data itself is reusable, as you start to have these core things that the business does available, you get more and more applications that want to attach to that and use it. If we guide it well, it becomes a thing that kinda takes on a life of its own. Over the last couple of years, as you've become a bigger company, as your customers are already starting to get more widespread with Kafka, what have you done in terms of that go-to-market organization? In other words, have you developed, customer success people? Yeah. Do you have more, you know, post-implementation capabilities? Yeah. Have you verticalized? What, what have you done to enable this? Yeah, there's, there's been, I, I think, significant maturity on our side in trying to help customers be successful. There's some amount of grouping and going after segments, so we know how to care for different parts of the market differently. You know, more attention for larger customers as they get to scale. Much more of a kind of prescriptive methodology. Like, now that we've seen a lot of companies do this successfully, we wanna help people get on to that path to success. Yeah, that's been a very significant effort for us, and I think quite successful. I think the test of this stuff is always in the harder times in the market. You know, that's when you see how well you've done by your customers. Are they really getting value out of your solution or not? Is when money's tight. I've been really proud of our performance, you know, through what's, you know, a fair amount of pressure on tech and tech spend, you know, over the last, whatever you wanna call it, nine months plus. You know, we've, we've done really well. NRR, our NRR has held up. You know, retention has held up, the business has done really well, and that's kind of people voting with their dollars in terms of what they really need and what they really don't. We, we're working towards the end, but I wanna, I wanna make sure we hit the GenAI topic. Let, let's ask our guys internally here. You know, where are we, in terms of GenAI initiatives within the, within the firm, and how is that influencing Mike and Scott, what, what we're thinking about in terms of our data strategy and possibly what we might be doing with Kafka? We said there can't be a session here without a GenAI question, right? Can't be. Hopefully, hopefully, a lot of you went to the breakfast keynote, right? All about GenAI. I'm doing another one right after, so, What are we doing? We're blocking it at Key. Technically, that was the first thing. You're blocking it less, by the way. I couldn't get- Blocking it less. ... a website three weeks ago with a dot AI, dot AI domain name. A few have opened up, so I appreciate it. Yeah. When it first came out, security said, we don't know much about it. We have concerns about intellectual capital. Our legal team had a lot of concerns, so they just shut down anything that said GenAI. Internally, we've created an advisory group, legal's in there, compliance, our tech teams. We've changed our appropriate use policy so that employees use it. They're at least held to the policy. We've opened up a team to do POCs, so we're working both with Microsoft, you know, the OpenAI that Microsoft is licensing, as well as what Google's doing, and collecting use cases from across the bank. I think what I, you know, what I heard this morning, I think is relevant to KeyBank. There's a lot more problems in the bank that have to do with structured data than there are-- that have to do with unstructured content generation, right? So I don't think Silicon Valley Bank crashed because they didn't have GenAI, right? I think interest rate risk management has, you know, all that stuff is structured data analytics, and I think there's still a lot of room for banks to leverage AI in general. I do think that what was said this morning, that you can take sub-optimal people and make them better if they're having... So I think of it more as augmented AI rather than, you know, generative. So if your job requires you to generate content or summarize content, you can be better with generative AI. I think the one use case that wasn't really spoken about this morning, I was surprised, is to assist our developers, right? I think it's really gonna help bring subpar developers up better, help you, code faster, find bugs faster, and, I think that's something that I didn't really hear, but we're that's one of the use cases we're looking at inside the bank, too. All right. maybe I'll pass it over to you, Jay, because, you had an analyst day, geez, was it more than a month ago now? It was a while ago. Yeah. It was the summer. Something like that. All right. It's in New York. It was fun. So talk about where you think that, that Kafka and Confluent fit in to the, like, let's call it the emerging GenAI stack. Yeah. Yeah, you know, I think I hear a lot of similar stories. You know, customers are looking at where they can put this into practice. A lot of it is kind of augmenting people's work. That's usually a combination of bringing together, you know, a pretty smart language model and some of the data they have in their organization. You know, we're really in the supply chain for that data about the organization. You know, that can be in the form of some kind of, you know, support or customer agent that's helping and is available externally. It can be some kind of internal tool that helps the people, you know, have the right answer with less training. We're really that supply chain for the company's data to make sure that it's there at prompt time, is up-to-date with what the customer's actually done. You know, it may not be obvious, but that's particularly important for some of these use cases. You know, the most frustrating thing is if you're, you know, interacting with some chatbot that's telling you about your, your state of your account, yesterday, right? Like, obviously, the reason you're interacting now is because of something you are trying to do right now. Yeah, we have, we have customers very much in that mode. Some use cases around the, the processing of, of data that can, you know, text data that can be done kind of asynchronously. Those are some of the areas where, you know, we've seen adoption. I, I think generally, even prior to the GenAI use cases, going back to the structured prediction, this was one of the original motivations for Kafka. Like I said, I kind of came in to run these analytics and machine learning use cases for data at LinkedIn. The first thing we had to do was figure out how to get all the data, get it to be correct, get it to be up-to-date, and fold it back into some of the user experience. In, in a sense, the GenAI stuff, you know, what I think it does is it, you know, emphasizes that kind of real-time, prompt, inference, time side of things more, and it opens up this technology in a significant way to businesses without having to build these kind of intricate custom models that are hand-built. Yeah -for that one problem. So, yeah, I, I think that's gonna be, you know, certainly a tailwind for Confluent and, and for the modernization of data architecture, just to help companies harness their data in this way. It's, it's your view that, you know, that, that need for driving more proprietary data, real-time data, into the query process with a GenAI model. Yeah. that'll drive more demand for real-time data? Yeah, I, I think that's right. Now, now, like, you know, I, I think that hits as this stuff starts to turn into real workloads internally, right? It sounds like for you guys, that's kind of. The process is starting, but it's not quite there. That's when I think we feel the full impact, and probably both in terms of the value for you guys, but also in terms of the kind of. I think of it as-- my big analogy is J.A.R.V.I.S. from Iron Man, right? I mean, Iron Man had J.A.R.V.I.S. there to talk to all the time. I think the GenAI is gonna make voice as an interface much more comfortable for consumers and business. If they're using their voice to talk more, they're gonna ask for more information more frequently, which will drive the need for more- Yeah ... more demand for data in real time, more analytics. You can get in your car and talk to, you know. I think people get much more comfortable. If they're comfortable enough talking to Siri and Alexa, it's just gonna get better and better, and that conversational will happen, which they'll be asking for more data, more frequently than they do today. They're not gonna call the call center, because they got to find the time to call them and all that stuff, right? Is that demand for more real-time data at inference time? Is that enough to be an incremental revenue driver or growth driver? Do you also think that you could have some kind of direct monetization or SKU? Yeah, I mean, I think the big force is that kind of data supply chain, that's a big thing, I think. There's more investments we're making to help augment that and make it easier. You know, do we connect into that ecosystem in the right way? Can we support the right kind of processing of that data and our stream processing layers? There's a lot that we can do to accelerate that, nonetheless, yeah, that, that data supply chain is one of the critical pieces for, you know, this whole movement around AI. I'll ask you this question, which, which we're asking everybody, sort of as a poll question. Yeah. Do you think that the incremental revenue growth from GenAI, if your business comes second half of this year, first half of next year, second half of next year, or 2025 and beyond? Yeah, I would say next year is when we'll start to feel it. I mean, I, I, I feel like the tendency- Sometime next year. to say is Beginning, first half, second half? Yeah, I mean, it's hard to, it's hard to tell, and it depends on what volume. I mean, we have real production use cases today. If you were like, "Hey, when are you feeling impact?" I suppose we're feeling some impact now. Right. When is it moving large numbers in large ways? That one's a little harder to call. I do think people tend to underestimate the impact and overestimate the speed that it comes for these kind of bigger technological shifts. Like, how quickly can you reorient complex interactions... Yeah ... in a bank to take advantage of this? It takes time, right? Yeah. Like, when does the bulk of the value for KeyBank or Confluent come? It's kind of when it's doing something real in production, that's kind of when we're going to feel it, and that will take some time. There'll be other companies that are maybe can be a little bit faster and looser. Maybe they get there a little bit quicker, but I still think it's not like a, you know, second half of this year where we start to feel the big impact. I think the companies that will feel that will be the ones that are kind of, earlier in that cycle, right? Where maybe you're, you know, buying something from OpenAI or some of the consumer applications that can jump a little faster. I think the enterprise use of stuff does have kind of a slightly longer ramp, but a lot of value behind it when it does happen. Okay. 45 minutes. Yep. That was fun. Yeah. Thanks, guys. Thank you. Thanks, Dave. Thanks, Mike. Thanks, Scott.