If you look at a modern IBM ZOS based mainframe, it's it's it does everything like it does. It runs all those old legacy applications and COBOL and RPG , but then it's got a virtualization layer that lets you run , you know, modern operate like you can run VMs on top of the on top of it. Right. It's also POSIX compatible. So you can run native Linux and Unix applications on it. So they keep sort of adding layers and updating it. So it never completely goes away, if that makes sense. Yeah. I feel like it's some it's some smart way of just keeping I call it almost a soft lock in, because if you keep the prices too high, then they are going to be motivated to migrate off and run away. If you keep them still high, but not high enough, you're playing around that Goldilocks period where we would like to move away, but it's so much work and so much effort and we're not going to save that much. That might as well not do it. I think they're very savvy from that point of view. It's it's the way they've they run this market is absolute genius. I mean, this is why IBM is is IBM and why they're worth what they're worth, right, is because they've got this momentum and this lock in behind this ecosystem that is just really difficult to get away from. It's true if like a similar thing that pops in my head is if you if you know any organizations or anyone who's worked with SAP, right, for for their, you know, running all their back end infrastructure and stuff. It's once you're in the system, you've got so much data in there. It's it's it's it's the migration away from it is just almost unfathomably difficult or or even Salesforce, similar kind of thing, right, where an organization has been using Salesforce for 10, 15 years. It's just gets really difficult to migrate from that sort of thing. So tell me then how did Kafka help you migrate off of the mainframe and then what does the Confluent IBM deal have to do with mainframes? So I think I think there's two pieces to the discussion with the Confluent IBM transaction, and I think the two pieces are that the high order bit is why would why would IBM be super keen on purchasing a company of Confluent? And I think the answer to that is control over the enterprise data plane. I think that's that's the high level move here and I think the second piece if we look at this through a slightly more narrow lens looking at mainframes is there's there's a couple of possibilities there. There's the possibility of, you know, retaining existing customers keeping existing customers from migrating away from mainframe or increasing their load, but also adding new capabilities to their mainframe infrastructure. You know, they're seeing enough of their customer base using Kafka with their mainframes that they're seeing it as a strategic ad for their mainframe business, which is core to what they do. But yeah, I have a lot more questions on how it will be an ad. But but before that, can you tell me a little bit about yourself? Like, how do you when did you even get expertise for for mainframes? I would say expertise is a bit of a stretch, but I have I do have experience where you mainframe. So I've been working in data infrastructure for about 15 years. But when I was first starting out back in 99 2000, I went to I went to school for computer programming analysis. And part of that this was in Canada and part of that program was a big push on mainframe technology. So particularly back then was what was called the AS400, which then became the I series, which is an IBM mid tier sort of mainframe. So if you think of ZOS based mainframes are really big ones . That's sort of your your A tier and then sort of your mid level B tier would be the I series or the AS400. So I went to school for that, literally learned how to write RPG, COBOL, a little bit of Fortran, a little bit of CL and a lot of DB2, which is IBM's, you know, relational database platform and learned a lot about the mainframe world. And the idea was in that program was that the guy who ran the program saw that there would be a need for developers in that space in the coming years, because a lot of the the original guys were getting ready to retire and if not have already retired, because a lot of that code and stuff was written in the 70s and early 80s. So, you know, fast forward 20 years, 30 years, those guys are, you know, on their way out the door. Right. So the program was established to kind of fill that niche, if you will. So that's how I got initially exposed to mainframes. But that's in what year was that? Ninety nine, you said? That was ninety nine. Yeah. So they were already getting ready to retire in ninety nine . Yeah. A lot of these guys. And there was already 400 is like this. No, that's that's even older. That is very old. So so the model I looked at is more. Yes, exactly. That's what it's the black monolith that sits in a server room and just hums away. That is what I'm more familiar with. And it's an interesting system, especially if you're used to coming from a microcomputer perspective. You think like a modern PC, it's a very different approach to computing. To give you an example, a box like that would actually be two computers combined into one. So back then, you didn't have all the crazy CPU cores that you have now. So what you would have in a box like that is you would have , you know, an A side and a B side. And the A side would be a CPU core, a bunch of memory, a bunch of storage and an IO system. And the B side would be a hardware mirror of that. And the idea was any work that would happen on your A side, which would be your primary side, would be automatically replicated to the B side. And so it had full built-in hardware redundancy. And it literally has a physical switch on it that, for example, if the A side were to fail for some reason, maybe the power supply goes on the A side or there's some other, there's a software update that goes wrong. You can literally turn a hardware dial and fail over to the B side and pick up exactly from where you left off. This is almost like, this is like what we do today, in a way. Yeah. It doesn't have to fail over. So what's interesting, if you're of a certain, shall we say , age group, a lot of what you see in the industry today has already been done before. With, you know, fail over and redundancy and in these main frame systems, it was just a lot of it was done through, you know, custom hardware, proprietary and custom hardware. And what you see these days with open source and systems like Kafka and, and other various big data systems is, is instead of using software, you're using, or instead of using hardware, using software to essentially do the same thing over commodity hardware. So you're, you're taking the hardware of the equation and using software to make up for that hardware. Which first makes it cheaper, but also critically probably makes it higher availability or more automatic because at the end of the day, I was imagining if you need to flip a switch on the hardware, you still need to call somebody to go and physically flip that switch. Yeah. There's also, there are ways you can do it through software as well. I was just using that as a, as an example to really illustrate just how unique these systems are compared to a modern, a modern infrastructure that we would build on today. But yeah, you could do it through software as well. Okay. And in your career, have you worked with mainframes or seen people work with mainframes? Yeah. So I did a little bit, um, when I was in college, but the, the main re-exposure to mainframes was probably, gosh, I should, before I just started at Confluent was probably about, oh, let me think, probably about eight, nine years ago. I started working in the Hadoop ecosystem, um, Apache Hado op, uh, worked at a company called Hortonworks. Um, and you saw a lot of companies migrating again, trying to figure out a lot of these banks, insurance companies trying to migrate away from, from mainframes or offload to mainframes, looking at other options. Um, and Hadoop was one of those potential options for them. Um, so I worked with it a bit there, um, uh, to migrate data off and, and realistically what you saw happen in this , and you'll see this pattern repeat again, as we get into the conversation about Kafka more. Um, as people realized it's really difficult to migrate off of mainframes, um, particularly in highly regulated environments like banking, insurance, things of that nature . Um, so what ends up happening is you generally end up running parallel systems where, so you've got the mainframe and then you've got a new system that runs parallel to the mainframe, um, for, to add new capabilities to it. Um, it's typically what I've, what I've seen happen. That's what, that's what you saw. Okay. Um, and also just a side question about Hadoop, because I'm , I'm curious, how did, how did that work? Is that similar to what you will try today by just, I guess the idea is just migrate the data off of the mainframe and have it in the data lake, and then you will figure out what to do with it. Yeah, basically, um, something similar to that. Um, basically how can we re reduce our, our reliance on mainframes because you get into the billing cycle of a main frame, which is quite expensive and how it works. Um, so again, coming back to this pattern of everything, things that people think are new today have actually already been done before. So if you think of, um, um, uh, uh, uh, uh, dynamic billing or, you know, usage-based billing, um, if you think of something like Confluent Cloud, for example, um, IBM basically figured all that out in the 80s. Um, so mainframes are built on a usage-based basis, so the more work you can offload from your mainframe, um, to a less expensive system, uh, the more money you're going to save. So people were always looking at ways of how do we reduce our, our workload on the mainframe, um, to reduce our spend . What's also interesting is that, you know, Hadoop was a solution to this. Kafka was a solution to this. I assume that people are using things like Databricks, Databricks and Snowflake today as well to, to migrate Alpha mainframes. It, it appears to me that this is largely still an unsolved problem. It is. And I think it speaks to what I call data gravity. Um, like it's, it's a combination of data gravity, compliance, and reliability. So data gravity is this idea that once you get so much data into a system or location, it gets incredibly difficult to move the data away or out of that system due to the volume of it and the volume and also the density and the requirements around it. So these systems have been running since the 60s and 70s and so have tremendous amounts of data. The other piece is, again, the reliability. These systems are designed to be bulletproof, redundant hardware systems, software failover. Anyone running a mainframe will have a contract with IBM where if a complete hardware failure happens, there will be a technician on site within hours to replace the hardware. So literally, these systems are built and designed and supported in such a way for zero downtime. You also have a legacy of code on there that has been built over 30, 40, 50 years that is incredibly robust, very reliable, very well tested, that meets high regulatory requirements in different industries, right? So it's very difficult to sort of migrate a code base like that. That's so reliable, so tested. When we say tested, you mean tested in production, right? Yes, it's been running for 30, 40 years, right? Reliably. Yeah, I'm just saying it probably doesn't have a full suit of system tests. Not in the modern sense, like unit testing, although there is more of that type of thing in more recent additions to the mainframe code bases that I've seen. But yeah, but it's more the stuff has been extremely well tested, both by engineers directly, but also just running in production for long periods of time. And it's very much a mindset of if it's not broke, why fix it, right? Exactly. And you were talking about data gravity as the thing that's keeping you on the mainframe, but I'm imagining also that the intricacy of the code of how all these different programs talk to each other, and how perhaps little and few badly understood it is, you know how it is like in a monolith today, or even in a coupled microservices architecture, you remove one thing, you risk breaking something all the way over here. And I just assume that that's like 10x in a legacy code base in the mainframe. Well, it's also some of these systems you're just not allowed to break, because the government will in some cases come after you if they break, right? Because it's people's financial system of record, right? So people are very nervous to touch them. But it's also, you know, it's the old adage, right? Where, oh, who wrote this awful code? And then you realize it was you like six months ago, right? It's that kind of... So it's hard to find people to dive into these systems who understand these code bases, and have the expertise to even migrate off. Now, not to divulge, not to go down too far another path. This is something where, again, a conversation around AI could be quite interesting as far as how it could help you navigate that complexity, right? But yeah. Potentially, yeah. But yeah, what I'm seeing here is that, like, maybe you can save a few million dollars a year, but your downside is way unlimited, if you break something. Risk, right? Risk versus reward. Exactly. Yeah. So it ends up not being worth it. Well, okay . Please continue telling me about the experience with Kafka. You didn't get to that Kafka in the mainframe and what you saw. Yeah. So I was early days at Confluent. So I was number 47. I was one of the first engineers in Europe. And how I got into there was essentially by working at a company called Hortonworks, where I started playing with Kafka as a way to get data in and out of Hadoop. So when Kafka, when Confluent started, they reached out to me as one of four people in Europe that had Kafka on their CV and said, "Hey, what do you know about Kafka? Are you interested in coming to work for us?" And I'll never forget my first interview was with Jun Rao, one of the founders. And he basically threw a producer at me, a broken producer, and said, "Tell me what's wrong with it. Here are the Java docs. Tell me what's wrong with it." That's cool. So that was kind of, and I solved the problem and explained to him how essentially how batches work and how LingerTime works and how you might want to adjust those parameters depending on the use case to deal with latency and things like that. And that's kind of how I got my foot in the door. And then from there, as one of the first technical people in Europe, I started helping build out the company. I was doing support tickets, but I was also doing hiring of the first SEs and SA, so sales engineers and solutions architects. So I was kind of doing a lot of the technical vetting, also doing some developer interviews as well. And I was working with customers across the spectrum because the company was so small back then. So I was working with, you know, financial customers. But I mean, when I first started it, we, I also remember that, you know, like we had less than a million dollars in revenue and like most of our revenue came from one company. That was, we'll call it a very large streaming company. And leave it at that. So I'm not sure how much detail I'm allowed to go into on these things, but yeah. And so, but I got to work with a lot of different companies, including in financial services, in insurance company, insurance, also hedge funds, you know, the gamut. Telco did a lot with telecom as well. So that's how I got involved. And one of the use cases that came up, you know, I'd say probably about a year and a half, two years in as Kafka got more and more traction, you know, it started out usually with really the hyper, you know, like the really advanced tech companies, your, your, your large video streaming companies, your, you know, your Silicon Valley startups. And from there, it sort of branched out into more traditional organizations like banks and things like that. And so I started working with a couple of banks, one in Canada, um, called RBC was doing a lot of work around, um, Kafka and mainframes. Can you give me a rough timeline? What year is this? That's probably, gosh, gosh, what are we? 2017, 2018, probably into 2018, 2019, somewhere in there. It was pre-pandemic. Let's put it that way, for sure. That 's kind of my dividing line these days, you know, the, the old world versus the new world, um, pre- pandemic. So, so then timeline wise, maybe 2014, 15, it was mostly the, the tech companies using Kafka and, and trying it out. So I was playing with Kafka in 2015 because I think I started Coughlin in 2016, maybe end of 2016, somewhere in there. Um, so, and that was like, when I was playing with it, it was like 0.6 or something. 10 years ago, by the way. Yeah. Wow. That's yeah. I can see the gray hair here. Um, yeah. So, so yeah, it was 0.6 and going from there. So, um, but yeah, the way it tends to work in financial services too, is once you kind of get the first firm interested, first bank, for example, oh, that's cool piece of technology. You want to play with that, um, and do a deal with the first bank. The rest tend to follow because it's kind of validates you in the space. You've gone through all the due diligence with one of the big banks already. Um, so once the first bank, we started working with them, the rest started following in line, but mainframe work in particular was with, I did some work for RBC, um, supporting them. And it was, it was the original use case for them was, was, um, mainframe offload. And so what do we mean by that is, is connecting Kafka into their mainframe, um, and using it almost like a cache between the mainframe and the applications that needed access to the data on the mainframe. And the reason why this was a critical use case for them is that the way mainframes get built, IBM builds on main frames, they build on something what used to be called MIPS. I think there's a different term for it now . Um, good. I'm trying to remember what the new term is, is it, is it MUX or something? MCUs I understand, medium service units, something like that. Okay. So yeah, but it's the same idea as MIPS. And basically MIPS stood for millions of instructions per second. The idea was how many instructions a CPU could execute in a second and how many of those you used in a given period of time. So usually it's like a four or five hour window, um, over a 30 day period and whatever, whatever the highest usage for that, for a given four hour period over any given 30 day period is what IBM would bill you for the month in usage. Okay. Um, so obviously that could get very expensive very quickly. Um, and so the idea with using Kafka was, well, if we put Kafka in front of our mainframe and we have all of our applications ingest the data via Kafka. So Kafka makes requests to the mainframe, pulls the data. Kafka, as you know, is an immutable log. The data sits in Kafka and all the, all the subsequent requests for that data come from Kafka directly. So you basically read from the mainframe once, then it's in Kafka and all subsequent reads just come directly from Kafka to the given application that suddenly starts to decrease the load on the mainframe. And by decreasing the usage on the mainframe, um, your costs drop and your costs drop by like orders of magnitude. So if you're spending a million dollars a year on your Kafka infrastructure, you're saving yourself like multiple millions of dollars a year on main frame charges. Um, some cases, some cases, orders of magnitude, like it's, it's, it's pretty dramatic, the cost savings. Um, so that was the first primary use case was that the, a lot of the banks and financial institutions realized was like, wow, we can save a lot of money just using this like a cash . The next use case on top of that was, you know, getting data in and out of your mainframe is, can be kind of obtuse. So by getting your data into Kafka, it suddenly opens up because you have this modern, more modern interface, this, you know, Kafka connect and then, or even just a straight Java interface into Kafka to expose that data to a lot more modern and different type of applications. So it, it stage one, it can save us a bunch of money stage two, it introduces a whole bunch of new, um, capabilities, right. Um, and it introduces capabilities that, you know, a modern developer can take advantage of, right. You're not having to go back to one of the old tim ers to figure out how do we get this data off this mainframe to this application. It's already there. And then the third piece to this puzzle, which is the next level is, okay, we've got this data in Kafka. We're now able to expose it in all these unique ways. Hey, wait a minute. We can use Kafka to validate this data, right? Using things like Kafka streams, for example, and schema registry, you can do all kinds of data validation in Kafka itself, which again, reduces load on the mainframe. Um, but also allows you to not just read from the mainframe, but these external applications can now read from the data off of Kafka from the mainframe, but then write back to Kafka. And you can do validation transformations on that data and come up with a richer data set, if you will. And can you also, because mainframes understand are inherently somewhat batch-based. I guess that also improves your real timeness of the organization. Absolutely. Absolutely. Um, now when we say batch on main frames, they are batched. These days, they're a lot faster than they used to be. Um, obviously CPU and architecture, um, has improved dramatically, um, in that regard, but yeah, so it can give you, because you're dealing with Kafka, you can now take that mainframe data that's in Kafka and do , you know, sub-second queries and analysis and, and all those types of things through either through, you know, something like Kafka Streams or Flink or, you know, Spark, depending on what your, your data architecture is. But, um, quick, quick aside then, um, so new mainframes have improved. Obviously they have new CPUs. Do you have any visibility if these organizations are still running the ancient old boxes that are 20, 30, 40 years old ? No, no, no. That hardware will be long decommissioned. So, so the way to, the way to think of it is, is on the ZOS machines, the ZOS machines is ZOS is a proprietary operating system, the IBM. And so what IBM does is they keep adding layers to it. So they added POSIX support in the late early nineties, I want to say. So it's full UNIX compatibility, um, running UNIX applications, whatnot. And then in the late nineties, when VMs started becoming a thing, um, they added, um, virtualization layers to ZOS. So you could actually run like Windows and other operating system, Linux, Windows, and you can mix and match all on this, this core infrastructure. So you'd have this, you have this, um, ZOS kernel that can run all these different layers of infrastructure, if you will. So what they do then is they essentially do a lift and shift, right? When new hardware comes out and your old machine's kind of getting to end of life, they can essentially migrate over from the old machine to the new physical machine because they have all these different virtualization layers and technologies they can use to, to, you know, uh, mimic the old infrastructure and keep the old code, code base running. It's like emulation. Essentially. You can do a lot of em ulation and whatnot. Yeah. It's, it's a little bit of a hack that works, you know, just throw more hardware at the problem and have it work better, really. Well, well, the thing is though, the hardware keeps getting so much faster and so much better that it's, it's, it works . Right. So as opposed to having to rewrite all your software, just lift and shift to a faster box and run an emulation layer. Right. And it works. Yeah, I know. This is, this is a reason why I've been so bullish on things like Postgres for everything, because the hardware today is so good that, you know, Postgres can really do so much in your organization. You'll think you need something like a Kafka or some big data technology that's distributed can do a lot of throughput for your use case, but you really don't. The reason you would want Kafka here is more for the standardization and the APIs and the ecosystem rather than the raw power that the software provides, which again, as another aside, I think it's a little bit of a legacy decision, like the decision of Kafka to let's say not validate message bytes and other optimizations, just so it can get to that gig abyte a second workload. You know, if you have 90% of your use case, not need this, like if you're using Kafka for mainframe migration, we're talking megabytes a second of throughput, right? Yeah, basically. Yeah. Depending on the use case. Yes. You'll gladly, you'll gladly trade off some efficiency here for, you know, more validation, let's say. Yeah, correct. Correct. This is not, um, when you're dealing with mainframe, at least in the use cases I was working on, I won't claim to know all the use cases out there. Um, this is not high frequency trading or anything like that, where, you know, you're, you're, you're, you're literally running cables from your data center directly to the exchange to get that, to shave off a couple of microse conds of, of time, right? Um, so no, this is not that type of use case at all. Um, I, uh, I, uh, I also found the RBC, um, case study that you talked about. So I highlighted some stuff here as we were talking. I noticed one of the things they said, one of the results was greatly reduced costs. I'm sorry. I think this, you see this double now. Uh, but, uh, they said greatly reduced costs here. Uh, they were speaking some other stuff. They, it seems like this was a high read workload. So as I say here, it was produced a workload that was high in reads, low in writes. Correct. And they imply here that we had to keep the writes in the mainframe that was necessary, but the read workload was a candidate for elimination. Correct. And again, as I say here, they want to do it without introducing risk. So I understand it is pretty low risk to use it as a forward cache. As you said, just move whatever data you have, move it off asynchronously and your read, and your read workloads can, you know, read it whenever they don't need to access the mainframe for that. Exactly. So, yeah, it's proof. And here they talk about how it naturally started growing. Within the first six weeks after our launch, 37 teams started asking to use Kafka. So you really see this, uh, narrative that Confluent had get validated here, which was once you sort of liberate your data and put it in a standard place where everybody can access it, people organically start wanting access to it. Correct. Yeah, absolutely. And it starts to create all these sort of feedback loops of , of new capabilities and new ideas of applications you can build and, and, and, and, and, you know, these use cases. Right. So it's really quite an interesting thing. And I think, I think to kind of go back to the beginning of the conversation a bit where, you know, this is the mainframe aspect of it. But, you know, again, why is IBM interested in Confluent? And I come back to this thinking of, you know, what is Kafka? Like, what is it these days? Like the, the technical sense to set will sell you, well, it's, it's, you know, producers, consumers, a broker, schema registry, et cetera. Um, but I think that's actually a really myopic way of looking at it. I think these days Kafka is, is the protocol really, um, that's the critical, critical piece here again is the protocol. And to me, the Kafka protocol is like to the data layer, what like TCP is to networking, you know, it's that sort of foundational protocol that everyone supports now. Right. Because it, it, as you, as you're aware, but as, if anyone listening or watching isn't aware, there's multiple Kafka. Kafka vendors out there now, right? You've got pure open source Kafka, you've got Confluent, you've got Red Panda, you've got AWS offers a Kafka service. Microsoft's got something they're working on. They, so there's always, right. So there's all these, cause the key is, as long as the protocol is the same, what you 're running behind that protocol is almost irrelevant. Right . Um, that's how the internet works with TCP, right? You could run a Cisco switch or a Unisys switch or a, or whatever, right? As long as they're all speaking TCP, it doesn't really matter. So to me, IBM and Confluent, IBM purchasing Confluent is a play, um, for that data, you know, that enterprise data, um , um, data plane essentially, right? Because they will have, and will now do have huge influence over the evolution of the Kafka protocol and where and how it gets implemented. Right. So, so, so that is, that is the high level strategic view, um, um, ongoing. And then obviously, you know, that feeds into workloads, like, you know, what's happening on your, uh, on your mainframes, but also feeds into all of the AI, agentic AI workloads. So where I could see this going, for example, is, okay. Um, you've got your mainframe, you're using Kafka in front of your mainframe. Fine. That's fine. Um, we've got these cool agentic AI tools we've built that can run either on your main, on your mainframe. Um, with Kafka to feed it real-time data that's running on your mainframe, your AI is running on your mainframe, getting fed real-time data from Kafka, generating more workload on your mainframe, creating more value for the customer, but also more billable, you know, cycles for IBM, right? On the mainframe. Um, so that's kind of the loop I can see, um, happening here. Um, one possibility of many, but that's, that's one that pops out to me, um, right away. I have two things to show you. Let me try to find the second one though. Uh, so actually everything is billable by IBM now that you said, I mean, even if it goes to Kafka, Kafka is IBM now. So that's billable as well. Uh, let me show my screen again . So one thing that Confluent developed in 2022, as I was doing my research is they introduced a proprietary IBM MQ source connector and sync connector. So the source connector means you can read from the MQ and it goes to Kafka, but they also interestingly introduced a sync connector. It was on the blog post somewhere. Let's see if I can find it. Um, perhaps this one. Let's see. Yeah, there we go. So as a hybrid computing model has evolved organizations scrambled to find a solution that can optimize mainframe application performance while keeping up with demands. To address this, they recently launched the MQ source connector and the MQ sync connector to unlock the bi-dire ctional flow. A few time data events to the mainframe. So this is already kind of been done. And I found it really interesting that they introduced the sync connector as well. So that does show that there is some desire to at least have the data go back to the mainframe for further processing. And yeah, this was a few years ago now. Yeah. So I think, I think essentially they're going to create a feedback loop and they're going to be able to run your agent. It's Watson. Is there, is there AI? I mean, one of the AI models, but it's the, it's the Watson program is how I would describe it, which is all their AI models. And I would see them using again, that feedback loop of, you know, ingesting, you know, getting data out of the main frame of Kafka in a standardized way that all these applications can consume. But then all these applications again, pushing data back through Kafka and then into the mainframe and running these agentic workloads on them on your mainframe to, to accomplish whatever the given business case is. I think that's, that's the way I see it. Cause that generates, um, again, what I used to be called more MIPS on your mainframe to generate more billable revenue for IBM while adding more value to the customer. Yeah. And it's not only about MIPS. I mean, even if you're running, so there's this thing here called ZIIP where it's a separate processor on the mainframe where you don't run, like it doesn't bill you for the MIPS. If stuff is running under ZIIP. And I thought it was genius because even if you're running the ZIIP and let's say it's 10 times cheaper than MIPS, they've still got you locked in into the physical hardware box. So they can still charge you in the future. They can charge you now, or they can just force you to update the hardware. Like you're in the treadmill of, okay, I need to buy the newest mainframe now because this one is running cold, et cetera. Absolutely. Absolutely. Um, it's, it's all about, it's all about creating feedback loops, right? These, these feedback loops where everything keeps looping back to, you know, in this case mainframes, but, but IBM, you know, software, you know, hardware and software services, right? That's, that's what they're trying to do here. Um, that's exactly what they're trying to do. Um, and, and I suspect we'll be quite successful at doing it. Um, because you've already got, if you're a huge organization, you've already got these mainframes, you're already spending a lot of money on them. It's much easier to say, Hey, that new agentic AI workload you want to do. Hey, we can do that for you on the main frame. Right. And we can even plug it into Kafka. So all your existing, you know, um, data plane architecture and infrastructure can now just, you know, you're already running Kafka and these other parts of your business or whatever. Great. We can plug that into the mainframe. No problem. Yeah. IBM are just geniuses at locking people in and at basically milking a cash cow, which isn't the mainframe. They, um, I've heard a lot of people complain about Oracle 's licensing and I would say, well, you know, you actually need to go back to the, the, the OGs, which are IBM. Um, they are, uh, the original sort of licensing monsters, if you will. Um, yeah. Yeah. No, I think both of these, um, companies are actually pretty good. If you look at the last, let's say a few years , their stock price has been going up way better than conference stock price. If we compare in the last five years, well, they do, they do very different things. They do a lot of different things . Right. So. Yeah. Um, uh, but I'm just saying, you know, as companies are basically judging their stock price, you know, as much as we see these companies as dinosaurs and companies that don't innovate in the technical space. Uh, they are innovating in the financial space, which is the goal of any company, meaning they're successful at making money for whatever reason. Yeah. IBM is, is a fascinating and mainframes are fascinating. I, and a lot of people don't realize like most of your modern life probably actually runs on some type of mainframe. Um, if you think about it, like your bank account, unless you're running one of the, unless you're using a new neat, one of the new neobanks in the UK, that would be like a, a Monzo for example. Um, you know, who have completely built a whole new architecture from the ground up, you know , using things like Cassandra and Kafka and other, and other platforms. Um, anyone using like an HSBC or Lloyd's or, uh, you know, JP Morgan or, you know, Bank of America or any of the, you know, any major old school bank like that. It's all running on mainframes, all your bank account details, all your transaction history. Oh, I paid this guy some money. Yeah. It'll run in real time Kafka stuff. And for real time updates and that, but the end of the day, it all lands in a mainframe. That's where it's ultimately reconciled is on the mainframe . You know, the funny thing is that even a Monzo uses a main frame indirectly because I think, I think they're either based on one of the bigger banks having accounts there, or even if they work with a central bank, the central bank has a mainframe. Right. So you can't escape it, but all your insurance. And I mean, insurance from the car for the car you drive to your health insurance to, um, I'll give you an example. Um, a couple of years ago, I was back home in Canada visiting and I walked into the insurance office, um, to take care of some business. And, uh, the woman working in there is small town when she, she pulled up the policy and was telling me what was in the policy. And it was what's called, uh, an old green screen, 5250 emulation, which is the old IBM mainframe green screen . If you want to, I don't know if you want to pull up a screenshot of that or whatever. And that's what I learned to code on in college. And it's literally, you use arrow keys to go across the, the different fields to type in, you know, the person's name, address, et cetera. Um, and, and it's still being used. And it is a lot of retailers, even in the UK, um, uh, where I'm based in Australia at the moment, Melbourne, I just moved here six months ago, but I was in the UK for the last 15 years, which is where obviously we met and worked together. Um, a lot of retailers too, you go in, if you see the, the screen in like, uh, um, a Halfords or something like that, you can still see the old, you know, it to nerds like us, it'll look like a glorified SSH session. Um, but it's, it's, it's essentially it's, it's mainframe terminal window is what it is. Um, so all their inventory systems and everything are still on, on the mainframe. That's wild. Yeah, that's wild. It's very normal, very common. It's everywhere. Most of your life runs off a main frame and you don't even realize it. Most people don't. Yeah. I, I wonder if we ever get to see the end of them. I don't think so because one thing that IBM has been tremendously clever about is not being stagnant in that space. Like they keep evolving the technology again. Like when VM started becoming a thing in the late nineties, right? Suddenly IBM added a virtualization layer to the mainframe. So now you could run those workloads on your mainframe, right? Kafka is a thing, right? What's IBM doing? Oh, we bought Confluent so we can influence the protocol and we can now sell bundle Kafka with our mainframes as well as our other services to keep you using your mainframe . Like they keep evolving the stack, um, in a way that's frankly is, is really impressive, um, to, to update it for, for the new paradigms and the new technologies that people are interested in. Yeah. Yeah. I was surprised by having AI agents on the mainframe. That's just, it sounds so ridiculous, but it can work. The things that mainframes really excel at is, is IO. Um, and that's due to their historical batch based processing, right? They need really good input output and that's where they destroy any sort of microcomputer you can think of, right? Give me the latest AMD chip or the latest Intel chip or, or even, you know, the latest arm-based chip. I mean, a mainframe will absolutely wreck it in IO because that's what, that's what they were built for. Interesting. I want to bring the discussion back to Kafka for a second. So we're talking about, uh, IBM having influence over Kafka and I pulled up this photo here. They, I don't know if people realize this, but the Kafka community is smaller than people think it is, even though it's bigger than it's big. But the technical community or IE, the community that directly contributes to Apache Kafka code base, that's a small one. And that's basically confluent. And we have, I pulled this chart, I ran the numbers, it was a lot of work to run these numbers because I had to go to each committer and figure out what their LinkedIn history was and what year they worked at, what company and attribute commits like that. Uh, but I ran a historical one from 2010 to 2025. And I, this is the percentages of commits by people, by company, where they were working at the time. As you can see, conference is comfortably in the number one spot at 70%. We had LinkedIn at the second spot, which tells you how old this chart is because LinkedIn haven't committed to Kafka in, it might be even 10 years to be completely honest. That literally would have been Jay in June and Niha and a few other people, maybe Ismail and a few other people. Yeah. Basically, then we have this open source community in Taiwan. which is a really cool one. And this, from what I understand, they're really just independent people. Um, so working off to their free time. So contributing to Kafka, they don't have Red Hat, which these are more, um, recent ones. So a lot of people from Red Hat do work on Confluent. This is again, by the way, IBM, I don't have some people. I don't know. We have a little bit of Ivan, Claudia and Horton works here . They merged a few years ago and all these other companies, I mean, they do some contributions and they are somewhat active. But again, the majority of the KIPs being introduced is all by Confluent. And if I, I'm sure if I, if I run this chart again in just the last three years or something like that, I'm sure Conf luent will be even higher than 70%. And you probably get some contributions from, from, from, from Red Panda as well. And a few of the other, I'm sure AWS has definitely committed a few of a bit of a sore point there. AWS doesn't probably do as much as they should for the open source community. Um, and I don't think that's just a, a Kafka thing. And I think that's a open source thing with AWS, but there 'll be some contributions from them. Um, but yeah, I mean, I mean, again, that comes back to, again, what we were talking about. Why is, did IBM buy Confluent? It's again, the way I see it is, is the Kafka protocol. Again, it's the TCP of the data plane. And, and, you know, who, whoever to, to, to, to quote, to paraphrase Dune, you know, he, he who controls the protocol controls the universe type thing. He who controls the spice controls the universe, same thing , right? They control the protocol. Um, they have tremendous influence over, over the entire global enterprise data plane because Kafka has just become so ubiquitous. Yeah. Yeah. It makes it seem like a good purchase. So from that point of view, I think they probably will not stop contributing to Kafka. Uh, or they won't ruin it or have it stagnant per se, because their incentive is just to keep it alive. And, you know, their power comes from having that little influence where if they need to change something that's in a way, that's a little bit more favorable to them, maybe they can do that. Absolutely. Yeah. I don't think it's going away anytime soon. I don't see it. Um, I don't see it radically changing. Well, especially with the open source product, um, uh, you know, it, it's not going away. And I don't think my take is I can't see IBM wanting, I mean, never say never, but I don't, I can't see IBM really wanting to screw this up too much because it's quite favorable for them. Um, and I think it's really important for them to have that influence and to keep those customers involved in the Kafka ecosystem. Um, cause again, it creates a feedback loop for them, right . And to their other products and services, whether it be mainframes or professional services that they offer, agent ic AI, et cetera. Um, yeah. So do you have any guesses on how they may monetize this? Like what happens to Confluent Cloud to its own plan? I think Confluent Cloud becomes part of IBM Cloud eventually. Um, that would be my guess at some point in the distant future, they'll start to, you know, what you'll see is you 'll start to see, it'll be Confluent Cloud, but you'll, if you look in the headers or whatever, you'll start to see, you know, IBM data centers and whatnot in the headers, um, for URLs and stuff. Um, I can see a migration like that happening, so they'll, they'll want to move stuff into their own data centers to again, lower costs because Confluent was a multi-cloud vendor, right. It was across AWS, GCP, uh, Microsoft, um, that being said, they'll want to be sensitive towards customers who insist on having that multi-cloud approach. So I think they'll still keep multi-cloud, but I think there'll be more of a push again, to run on IBM's cloud as much as they can, right. Cause that's again, a much bigger profit margin for them cause they own the whole stack then. Um, I think, I think it's interesting. I don't know what's going to happen with like, if we take an example of one of the banks, he's using Kafka, you know, to, to offload from the mainframe to, to reduce, uh, the workload on the mainframe. I don't know how that'll play out. Like I can see a goodwill approach where they don't charge anything more for Kafka with the idea that because they have the sync, that they're going to help you sort of push data back on to the mainframe and make up their money that way. Running, running, running your agent, uh, you know, your AI agents and whatnot on that data. Um, the other option is they could even make like the on- prem stuff and make it more like the cloud stuff, right. They know how to do it clearly to make it more, um, you know, uh, uh, uh, user, um, you know, a usage based billing on Kafka, even for on-prem, right. They could totally do that. They have the skillset and the technology to do that. They do it with the mainframe now, right. They could take that approach. So as opposed to a flat licensing fee, we'll make it like MIPS and we'll, we'll, we'll, you know, do a usage based on your Kafka as well as your mainframe. They could do that. Um, yeah, it's, so there's a couple of different ways that could cut this. So I definitely see them, like I said, I, I see them definitely pushing, trying to push customers more onto IBM cloud. So they own more of the stack of higher margin. Um, I see them pushing more data through Kafka back to the mainframe, trying to find ways to risk that for these big financial institutions. Right. Um, cause again, the more data, more work they can get on the mainframe, the more they're going to profit for that. And the more sticky it becomes. Yeah, exactly. The stickiness is a big thing. Right. So, so yeah, it could go all those ways. It could be a case of, um, it can also become a bridgehead for them into businesses and organizations. They don't currently have a deep relationship with. Right. Yep. Yep. Yep. That's a huge thing. I was thinking about like just buying the customer base off of Confluence and having an, unleashing the IBM sales team on it. That's worth a lot. So, so like IBM's got all the traditional big banks, insurance companies, all those old school, you know, big mining companies, you know, companies that make real things , you know, companies that make tires and oil. And they've got all that relationships already. The Kafka, I think the value at a new customer base for them is all the really tech forward companies, right? All your startups and your Ubers and your, and your, you know, um, just eats and your, all these kind of, you know, sort of new wave companies. It helps them get their foot in the door of a lot of those companies, um, who normally would look at IBM and just laugh, right? Like, no, you're an old legacy company, right? We don't want to deal with you. We've, we're open source. We build our own thing. Now IBM can walk in and we'll say, Hey, actually we're, we 're now the Kafka guys. Come talk to us. We've got some interesting stuff. It's, it's a similar approach they took with Red Hat, right ? And HashiCorp too. And HashiCorp as well. Like, Hey, no, we're not just big old IBM, you know, main frames that we, we, we, we, we are one of the major Linux providers in the world now, right? With Red Hat and not just Linux, but also Ansible and Red Hat had their own Kafka implementation and, you know, um, yeah. And HashiCorp with all your, you know, your vaults and your security and Terraform and all that, right? Terraform is huge. And now they have the leading Kafka. So suddenly they're a modern player almost. They can tie all these products together. Tie all these services together and offer you a bundle where, you know, Hey, tell you what, you come build it on IBM cloud. We'll give you a, you know, Terraform for free. We'll give you really cheap Kafka usage. We'll give you a, you know, we, they can make up the margin by running on the cloud, for example, so that you do these package deals, right? And switching to a little bit of an economic thought, I actually have this theory or this thesis that we're going to see a lot more bundling in the data infrastructure space. Yes. I don't think it's an accident that a company like Conf luent sold. Let's not forget Confluent sold itself to IBM. It was looking for a buyer. It would not have agreed. I mean, it sold for 11 billion. I think the IPO was around that number as well. The market cap of the company. Yeah. It was around 11 or 12, I think. Went crazy up to like 30 or 40 billion during the 0% interest days, which was just, you know, the whole market was crazy. But yeah, so it, it, it, it, investors generally got their money out of it of what they put into it. At least the early investors, you know, I mean, if you bought it at $40 billion, you're, you're probably going to be sad today. But yeah, but the whole market was crazy then. So, so I'm just bringing that point, this point that I feel like the whole data infrastructure space is a little bit too unbundled and overextended today. As we just say, what is the value of buying specialized software like, like Confluent or let's say Elastic or Mongo when somebody like IBM can come and they can give you a bundle of a lot more for a cheaper price, solving a lot more problems, reducing your customer relations, reducing the amount of due diligence you have to do. So, all of these things, and it's still a sort of an 80, 20 thing, because at the end of the day, if you're buying a Kafka, your main API that you're going to use are the produce and the consume. And then you only have some blockers, like maybe some schema evolution pattern is not supported by your schema registry, or maybe you're lacking this connector. But I think it's a big question, how, how big a block, like , are those issues actual blockers for, for a deal? Or if you can get 80% of the benefits for a lot less price and have everything bundled together, like, you'd probably just choose a bigger vendor. Well, it's the old expression, no one ever got fired for buying IBM. Yeah. Because you do not, it's like buying Microsoft, right? You know, they're not disappearing tomorrow. You know, they're going to be around for a long time. Right. They tend to understand the enterprise space. They tend to, you know, not to, not to name names, but there are certain other very, very large companies that like to kill products very, very quickly with little to no notice. You know, I don't want to name names here, but that's not on IBM. I can think of a certain search engine that likes to do it. Yeah. No comment. Right. So, you know, you know, it's going to be around. And again, as a data infrastructure guy, when I look at the data infrastructure spaces, and I know we've talked about this before, we were talking about databases the other day offline, and there are just so many different databases now and so many different niches. And it's like, even if you eat and breathe this stuff, like , it's impossible to keep up with it all. So, if you're a big company, or even a mid-sized company, right, and you say, I have this problem, and someone like IBM walks in and goes like, okay, this is the database you need. This is the ingestion stack you need, you know, Kafka, and running DB2, or whatever it is, or your big bank, and you can use your existing mainframe that you already have people who understand and whatnot, right? Like, it just, it takes a lot of the pain and confusion out of the market, right? As opposed to having to stitch together 20 or 30 different systems yourself, they've got a bundle for you. It's the same with Microsoft, right, and their infrastructure, where many moons ago, back early in my career, I was a bit of a, I was a Microsoft engineer. And I, not for Microsoft directly, but for an MCP, for a vendor, and, you know, I could walk into a customer site, and I could be like, okay, I'm going to build you a server. It's going to have Active Directory on it, which handles all your user authentication and everything, right? It does file sharing for you, right? This is in the early 2000s. Oh, by the way, it's also got this new email thing built into it, right? So it's all one clean bundle, right, where, and I can run it all for you and have it up same day, right? Very simple, very clean, very efficient, right? And that's kind of what IBM is doing here at the open source world, right, with, between the purchase of Red Hat, now Confluent, you know, HashiCorp, is they're going to bundle it all into a nice, clean package that's very easy to consume for these large enterprises. That makes it very hard to compete if you're a smaller player. That makes your deal, that makes your deal linked much longer, i.e., you just spend a lot more months hanging over prices and why they should choose you over somebody else. It's just very hard to survive as an independent data inf racompany, especially if you're in the database world. Imagine you're in the database world. There are, like, probably 100 database companies per year. What's interesting is the company I would be keeping an eye on to see how this is all going to play out, there's actually two companies, but unfortunately we only have visibility into one of them. It's Databricks and Snowflake. And the problem with Databricks is it's still private. So we just don't have that much information on it, right? Like, we get press releases every now and while, we've hit this run rate or whatever, but we don't have a lot of information. Although their roadmap does tell us some interesting things , if you look at their roadmap. But we get a lot more transparency with Snowflake because they are a publicly traded company. And so we can see their financials. We can see who their customers are. We can see what they're spending. We can see what their growth rates are. Because they're going to be competing directly with IBM on these deals, right? With, you know, because they are already competing with Confluent, right? So they've built something called Snowpipe, right, which is like their Kafka, essentially, to get more data in and out of their Snowflake system, right, out of the database. And Databricks, same thing, right? They had Spark streaming, which was not true streaming. It was micro-batch back in the day. I think they've now made it real time. It's been a while since I've looked at it. I need to look at it. But they're all competing. And you're absolutely right. It's this bundling of all these services together, right, where it's easier. Like, oh, I've just got my Snowflake bill every month, right, and all my guys know how to use it, right, and I can ingest my data, and I can transform my data, and I can do analytics on my data. And that's essentially what IBM's doing as well, right, with bundling all these services together. So Snowflake is a company that I'd be keeping an eye on in the space as well to see how that competition shapes up between IBM and them. Because Snowflake has a vested interest in getting customers off the mainframe as well, right? Everybody does. Right. Everybody does. I was posting some numbers on the mainframe. IBM, first of all, the mainframe usage is growing in the world. IBM had their killer year in 2025, the best year of, I think, selling mainframes in the last two decades. So it's higher than ever. Their growth rate was around 50%, I believe, of that revenue, something like that, which is insanely high levels . Confluent was growing at 20% at a smaller revenue run rate. The money they made from the software, from the mainframes, these MIPS and software licensing deals, is around $8 to $9 billion a year that they're making. And that's their cash cow, frankly said, because it's 80% to 90% profit margin. The software was written 20, 30 years ago. There's very little investment into it today. So there's so much money to be made in mainframes, migration off of them, or in serving mainframes. And I'm frankly a little bit surprised because I did some Googling. I did search snowflake.com and search for the exact name, mainframe. I could not find anything. Databricks also had very little resources about mainframes. So I'm curious, are these companies not going after main frames or are they going after another name? Is it implicit? I don't know. They don't want to talk about mainframes because it's like validating your competition, right? It's like, to give you an example, a confluent, you know, someone like when we were at Confluent, Red Panda would release some study saying, oh, we're like way faster than Confluent Kafka and blah, blah, blah. And you had two options. You either respond from a competitor's standpoint, right? You either respond to their claims, right? Which you could do and refute them. But then you're giving them oxygen. So the better alternative is probably to ignore them while still competing really hard with them. And I suspect that's what Snowflake and Databricks are doing is they are trying to get workloads off of mainframes into their systems, into their clouds, right? That's what they're trying to do. So they're not going to talk about mainframes. They're going to say, they're going to use other language like we reduce your, you know, your query times by X amount . We, you know, increase your ingestion, you know, by X amount. We reduce your time to value by Y amount, et cetera, right? They're not going to talk about mainframes. They're going to talk about, in business language, how they produce better results than the alternative, which in IBM's case is their mainframe infrastructure. And now Kafka and other things. Yeah, that's a good point. Confluent definitely does this. I think they also reply to people's personal blocks and make it seem like it's somebody else saying this and it's just their opinion, but actually it's the company's opinion . I've had them reply to me to some of the office of the CTO people that work there. And again, it seems like it's the guy replying, but it's actually the company in a lot of ways. Well, if you go up the food chain high enough, right? If the guy replying is high enough up the food chain, he's kind of speaking on behalf of the company, right? Yeah, yeah, yeah. Another thing I'm considering is perhaps these companies – there's also this thing in tech, which is you want to be seen as forward-looking. You want to be seen as, like, riding the edge of the hype cycle. You're an AI. You're in all these new things. You're cutting edge. And everybody wants to be seen like that because that's where the hype is and that's where the eyeballs and the attention is. But as we just talked, the real money is in the old stuff. The real money is in the old dusty mainframe running in some server room by some old bank that hasn't opened it in God knows for many years. But that's not exciting. And if you're the mainframe company, investors don't care about you as much, I think. It's not sexy. Exactly. So I think these companies are kind of fighting both – they 're trying to talk about all these new things, but they want to make their money off of the old stuff because that's where the money is. And the new stuff has no money. Like in AI agents, there is no money in AI agents today because there's so little people running them. Yeah, it's interesting. I also don't think they're quite there yet. They're cool, but they're still pretty raw, most of the AI agents I've played with. You know, they still make mistakes. They're still – they're getting better. Don't get me wrong. But they're still not quite there yet. But they will get there. And when they do, it'll be one of those overnight things. I think it'll be like the chat GPT moment where it'll be like, holy crap, right? It'll suddenly just blow up and things will start to change very quickly again. There's also a big difference in running AI agents for the enterprise versus on a personal level. In the last, let's say, three to four months, we've really seen the explosion on a personal level with cloud code and codex. And everybody is using it on their terminal, on their computer. We had OpenClaw. So we've seen that explosion already. But the enterprise explosion where I deploy a microservice that's an AI agent in my Kubernetes or whatever, that's still very early. And the problem is that I've heard this narrative since 2023. So people have been talking about these AI agents in the enterprise for three years now, and we've seen nothing. And that's what I mean when I say there's no money in these things yet. I think there's two pieces of that. One, part of it is hype, and it's three pieces. Part of it is hype, right? There's always a hype cycle before the thing actually does, hopefully, what it's supposed to do. The second piece is AI washing, right? Because, again, if you say, you know, if you and me start a company tomorrow and we call ourselves, like, I don't know, AI robot or something, and we're going to build autonomous robots that stack shelves using advanced AI, we could probably get funding, right? Because it's just so frothy and buzzing right now, right? In the market, right? And then the third piece is, if you build an AI agent and it's useful to your business, so you're, I don't know, let 's say you're Goldman Sachs or you're JP Morgan, and you start playing, they've been playing with agents for quite a while. And you find something that gives you an edge over your competitor, right? Maybe it lets you to trade a little quicker or a little more efficiency or gives you a little more insight to your traders. You're not going to announce that from the rooftops. No. Because that gives you an edge. Absolutely. Right? So I have a theory there are people running agents in successful ways right now. We're just not hearing about it because it's against their interest to tell the world about it at this point in time. Eventually, it'll come out. What people are doing with it, as all things do. But it's a very real possibility that people are running AI agents right now quite successfully to improve their business, and we're just not hearing about it yet because it's giving them a competitive advantage, right? Potentially. I'd like that take. I mean, it's certainly possible. But I want to talk more about AI Washington because this is a fat topic that there's a lot to dive into. The first one I want to dive into is the acquisition of Confluent, again. Because I see all of this, like, every company is trying to AI wash any product announcement, including mergers and acquisitions. If you open the Confluent acquisition, that the completion, which was in March of 17, 2026, which, by the way, I want to mention, this completed way faster than we thought. The initial announcement said that it's going to complete around the middle of the year. And we had it in March, which was a surprise for a lot of people. But continuing on, we control F AI, and we see 20 mentions. So IBM completes acquisition, the engine of enterprise AI and agents, you know. And AI is mentioned so much here, so much everywhere. We also have a quote from Jay that's also using AI, and the three main bullet points again. Activate the modernized mainframe in the AI era. AI ready, real-time data. This is AI washing. It's complete AI washing, right? Do you agree? Yes and no. I mean, there are genuine use cases for what they're talking about. Like we talked about, running AI agents on the mainframe, using Kafka to ingest real-time data for that. So I think that's legitimate. Now, the fact that AI is like every, whatever it is, 10th word in this thing or something is a bit obnoxious. But, I mean, that's marketing. That's where the market is right now. That's what the market wants to hear about. So if you're thinking about driving up your share price and adding, you know, shareholder value, you have to be talking about AI. And you have to be positioning yourself towards AI. So I get why they're doing it. So I can't be mad at them because that's like, that's what the market's demanding of them. When I think of AI washing, I think of layoffs. And I think of management decisions. That's what I think of when I think of AI washing. So, you know, who was it? Atlassian just laid off a bunch of people due to AI. Who else has? Is it Block? Yeah, Block is the other one. Oh, it's AI efficiencies. No, Mr. Dorsey, it's not AI efficiencies. It's because you have a bloated organization from the pandemic still. And you just, you're, you're not running your organization very well. AI has not given them the opportunity to lay off that many people. I'm sorry. It hasn't. It's, it's either the organization was bloated and that's poor leadership and poor management that the organization got so bloated and inefficient. Or, and it could be a combination of both these things. We actually do need these people or these, we do need people in these roles, but we can outsource this somewhere else where it's far cheaper to hire these people. But if we call it because it's AI, it, it, it makes us look good. Like we're on the bleeding edge, right? We're using AI and improving the business while also significantly lowering our costs. That's AI washing to me that these layoffs are AI washing. I agree. The layoffs are complete AI washing. I've seen it in Confluent and I've seen it in other organizations, seeing what people you get to work with. I think during the zero interest rate era, every company overhired massively in terms of amount of people, but also in talent of people. Like they just hired incompetent people, straight, straight to say. And the reason for that, I believe is pretty straightforward. I mean, if every company is hiring so many people, the good people are already taken. So you have to lower the bar in order to meet your hiring criteria. And I've seen this continue over the years. I think a lot of the companies have just overblotted. I mean, look at X. X is the best example. X was, I don't even know, did they have a thousand engineers or something like that? They laid off everyone in a day in the most abrupt, stupid way to do it. They caused a lot of, you know, trouble for people. And the website had a little bit of trouble, of course, when you fire so many people without a proper plan. But at the end of the day, it took them a few months. They stabilized it. And a few years later now, the site is mostly better. It has more features. Well, better is a relative term. It's, it's, it's, they kept it stable relatively, which I was impressed by. It does have more features. So I think on the engineering side, I think you're right. Now, without going too down a path that I don't think is the best thing for us to go down on this podcast. You know, on the social side, I think it's a toxic sewer, to be completely honest with you. So, so there's been a lot of negative causes. But if we just focus on just the engineering side of it, not the social side of it, I would agree with you. Yeah, a lot of inefficiency. And, and I think that's just one example. I think, I think there are many other examples. I would, I would challenge anyone listening or this conversation. Go out and look at your favorite software distribution, whatever it is. Maybe it's Kafka. Maybe you're a Linux guy. Maybe you're whatever, whatever platform it is that you're working with or on. Go look at the release notes for that platform from before the pandemic, during the pandemic, and then after the pandemic. Take a couple of different samples and see, has the number of features shipped increased or decreased? Has the quality of the product increased or decreased, right? And come to your own conclusion, because based off those data points, because there are definitely platforms I can think of. I don't want to name names here. I just don't want to, you know, I don't think that's fair. But there are definitely platforms where if you just literally look at the release notes of the quality and the type of features and the volume features and the quality of features from before the pandemic versus after the pandemic , it's a night and day difference. Where the quality just dropped off a cliff or the feature velocity slowed down or, you know, the type of features being released were like, like, how is this even really a feature? Like, you know, like where it's just something so simple, like we we fix some documentation bugs and they put that in as a feature, you know, like something really mundane. So, so yeah, I think it's and I think it's an industry wide problem, which is why I don't want to call out any specific platform or whatnot. But I've seen this happen in a lot of places. And I think it also comes back to our previous discussion about, you know, the software infrastructure space is just very, there are so many databases now. There's so many platforms. It's just there's so much diversity in a lot of these environments and systems that I'm not clear are necessarily good or required. And by diversity, I mean, specifically in the technology sense, right? Like, like, you know, do we need 30 different databases? Like, are there really that many niches for databases, right? The question really is, is there a market to support them? Well, yeah, right. And ultimately, the market will decide in any given niche what the best tool is, right? And the question, is there a market to support them, also depends on the companies themselves. So if a company is very bloated, it needs a lot of money for it to be supported. If it's a very lean organization, then maybe it could be supported. But I think given the zero interest rate era and all this hyperscading that we had, I think most companies in their current form, they cannot be supported. In the data infraspace, I don't think they can be supported by the market that there is. And I think throughout the years, as their funding dries out, as they get perhaps worse terms, and if they try to race again, or they probably just look for an acquisition, I think that will come to light. Like, I think consolidation is somewhat inevitable. Yeah, I think I completely agree with you. I also think this reminds me, you know, again, going back to my early days in college, I graduated in like 2001, which was the dot-com meltdown, right? So there were no jobs, right? And you saw a similar cycle where all these money, all these companies got all this huge funding, all got bloated, you know, petfoods.com being one of the Facebook examples and went to zero within a couple of months, right? And ran out of money and crashed and burned. And I still think we have a bit of a hangover in the software infrastructure space from the pandemic and the 0% interest rates. And I still think there's a lot of bloat out there. And I still think there are a lot of companies that are not right-sized and that are not going to make it. And actually, you know, the companies that really interest and excite me right now. So if you think of publicly traded companies, it's really easy, right? Because all their data is public. You can see the revenue. You can see the roadmap, et cetera. When the companies that excite me that are non-public, though, startups and things like that, are the ones that have been started in the last, like, two, three, four years . Because if they were started in the last two or three, four years, they missed out on the 0% interest rate funding. So right away, you had to have a good idea and enough sort of traction, grit, if you will, to start that company and get it off the ground and generate some revenue, right? Because there wasn't free money floating around everywhere. So I think we're coming through a tail end of a hangover from 0% still. I still think we're going through that. But I do think there are smaller startups and things that have started in the last, call it, what are we, 2026? The last three years, that because they started in an environment where interest rates were going up, where it was hard to get capital, where it was hard to get money, that those constraints automatically force you to have to have a real business, right? Or at least a higher probability of having a real business, because it's just so much harder to get started. Yeah. And, I mean, all of these other, going back to the older companies, the ones that got too fat, basically, they still have real businesses. It's just that they're geared up, or I say they fattened up for, let's say, a really long, this analogy of fatting up so you have food for the winter. They fattened up for a very long winter, assuming they will have, like, a very big total addressable market and that they can grow into it. And it just slowly turned out that those assumptions were not true. And I kind of applaud Jack for doing this layoff, even though it was originally, it was a screw-up to hire so many people that you have to fire today. I mean, a big layoff is basically a screw-up of the past. You just hire too much. But I feel like companies like Block have the decision of, okay, we made a mistake. Do we take the pain and do we fire people? Or do we make the organization leaner so it can actually sustain itself? Or do we not do it and do we eventually, let's say, die or go get acquired? Confluent is an example of this as well. And actually, there were news that came off. Some of Confluent got laid off now post the IBM acquisition . Mostly, I understand sales, marketing, finance, HR, etc., which you would expect after an acquisition, as IBM has that type of staff. Unfortunate, but, of course, part of the deal for an acquisition. And it's funny because I feel like Confluent had this path where it overhired, it tried to reach a total addressable market that was too large and it could not reach. If you read their investor reports, they said their total addressable market was $60 billion, then it was $100 billion. Yet, somehow, their revenue was only $1 billion and growing at 20%. So, obviously, something was wrong there. And now, obviously, at that point, right before the acquisition, let's say, Confluent is growing at 25%, 24%. They're at $1 billion. Their TAM is $100 billion. Something is evidently not right. In our likelihood, probably, your TAM that you can actually realistically catch is a couple of other magnitudes lower. And if you're Jay, if you're the board at Confluent, you have to decide, okay, we're too ambitious. We have too many people trying to reach a TAM that we probably cannot reach or doesn't exist. So, what can we do? We could lower the TAM we're trying to reach, which means we have to – a lot of these teams are now not useful to us. So, we probably need to fire a lot of people, maybe like 50 % of the company or who knows. That's very hard to do. We could try going into the TAM. You know, maybe we just don't have that killer feature yet. Maybe we innovate and reach that TAM to some killer feature with Flink or whatever it is. Or we go for sale and we have somebody like IBM buy us at a price that's not disastrous, $11 billion is a fair price. And we just call it quits. I think those were really the three paths that they could have taken. And the second path, which was trying to do the killer feature to grow into the TAM, I think they were trying to do for the last few years. So, I can speak to that a little bit, but please continue. How I'll conclude this is that the company's ambitions and shape and organization number of people is inseparable from its outcome. And if you want to have, let's say, a good outcome or a sustainable outcome, you have to flexibly change the organization's structure if your past assumptions don't apply. And that's a really hard thing to do. And I think very little companies are doing it, but something like X is an example of how you can do it. But again, X took, like, for Twitter to do that, it took it to sell to some crazy guy like Elon Musk, who's crazy enough to actually do it. But yeah. Yeah. Well, let's go back to that because the idea behind Conf luent was, okay, so we have these data pipelines. And then Confluent bought a company called Distributed Masonry, and this is all before it IPO'd. And Distributed Masonry gave them the capability of what is now tiered storage in Kafka, okay? And the idea was, and again, this comes back to this concept of data gravity we talked about earlier. The idea was, okay, Kafka is a distributed immutable log, so you can store data in it. Great. How do we make Kafka the system of record for an organization? So the idea was, by buying someone like Distributed Masonry , having tiered storage, suddenly Kafka can become a viable system of record in an organization. What do I mean by that? Well, instead of storing your data in, you know, Databricks and Spark and the Lake House or in Snowflake, right? You actually keep all your data in Kafka and you process it all in Kafka. So that was the idea behind Kafka Streams originally, was you've got all this data, it's coming into real time, we want to be able to transform and do things with it, we'll build this thing called Kafka Streams. What they then realized is that Kafka Streams didn't scale as well as they had hoped, especially for really large complex models and data sets. And so that's where Flink came in. They realized that Flink was the better solution. It was technically just a better solution. So that's why Confluent brought in the data artisans, was the company, and brought them in and they started doing the Flink offering with Kafka. That was the idea. And again, the idea was to make Kafka the system of record, you know, pump your data wherever you need it, do all your process, store all your data, process all your data, pump it to the applications you need. That was the idea, and that was the idea was to sort of cut Databricks and Snowflake off at the knees in a way, right? Because the data was all flowing through Kafka to get to those systems. And it was like, okay, well, if the data doesn't need to go to Snowflake, because you can process it in Kafka, even better, right? You now only need one platform, one system. Why do you need Snowflake? Why do you need Databricks? That, the challenge was, is Confluent could never struggle to get people to see Kafka as more than a dumb data pipeline. Yep. Right? And so it never became that system of record. It never got, people could not mentally model it being the system of record of storing all their data in Kafka. They just kept seeing it as a dumb pipeline to ship things to all these other systems. Correct. And, but now that you frame it like that, you can see why it was a smart bet, per se, and why management and investors would want to go towards that total jespo market. Because it's sort of like the, you know, it's like the main frame again. You know, if you have the data in Kafka, and you process it adjacent to Kafka with the Kafka adjacent technology, you 're sort of back to the mainframe. You've locked people in. You're going to get a cash cow similar to IBM's. Yeah, no, it was a smart strategy. It just, it didn't pan out. It didn't pay off. If it had paid off, then, you know, a totalable addressable market of 100 billion or whatever it was, made sense, right ? I mean, I think Snowflake's worth like 60 or 70 billion right now. And the rumors are that, you know, Databricks is, you know, something like 60 to 100 billion, depending on who you talk to. So, if that bet had paid off, it made sense. It just didn't pay off. And we can, there's a lot of conjecture and opinion around why that bet didn't pay off for them and what happened behind the scenes. But that's probably another podcast for another day. But, yeah, it's, it's, it's, it's, it's, the idea was, this was a solid idea. It just, it didn't pan out, unfortunately. Well, then, now that we know that it did not pan out and they got bought out by IBM, what do you think happens to these things? What do you think happens to Confluent post IBM? And in particular to, I have some notes here I wanted to ask you about, what do you think happens to Apache Flink? Not the open source project, but Confluent's offerings of Flink. What do you think happens to Kafka Streams? Confluent had some offerings there. And I think Warp Stream is also a good question, what happens to those guys. That's a great question. I mean, Kafka Streams is already kind of legacy, to be honest with you, even before the IBM thing. There are people using it, don't get me wrong. But it really was kind of deprecated by Confluent, in my opinion, in a lot of ways. For Kafka Streams, it's still pretty active. I mean, yeah. K-SQL was abandoned, but Kafka Streams. Yeah, K-SQL is dead. Yeah, I mean, okay, yeah, it is. Don't, fair, it's a fair call. But the real push was Flink, right? So yeah, like streams are around, people were doing things with streams, but Flink, Flink was the golden boy, right? Like, it's where all the resources went, right? Yes, yes. So yeah, it's not fair for me to say that it was, that streams was deprecated or not. It's just, you know, it got 10% of the resources, why Flink got 90% of the resources. Okay, so, or whatever, you know, but there's just a large ratio difference there. So yeah, so what happens with Flink? Does IBM keep Flink? I don't know. Does, like, what's IBM's take on streaming and on a streaming? Like, they could keep running with Flink and again, push it as a competitor to, you know, Databricks and Snowflink, right? And keep pushing it, either as part of Confluent or as an independent product. Because they have all those experts on staff and all those engineers on staff now, right? They could do that. Run it on your mainframe. Why not? They could do that. Whether they will or not, I don't know. To me, again, the high order value was in Kafka and, you know, those pipelines and controlling the Kafka protocol. That was the biggest value add for IBM. Again, Flink, I don't know. I don't know what they're going to do with it. As far as, you know, what happens with WarpStream, I think WarpStream technology just gets folded completely. WarpStream goes away completely. Branding eventually goes away, all that. WarpStream by Confluent by IBM. Well, it just becomes, you know, Confluent, WarpStream. Or IBM, WarpStream, whatever. It will all just consolidate under one brand, essentially, at some point. So I would see, I think WarpStream goes away sooner than later and gets consolidated, possibly under Confluent. Confluent WarpStream or something, right? And completely elder branding, all that goes away, would be my guess. And then over time, as IBM involves the Confluent brand, right? Because, I mean, remember Red Hat's still around, the brand and that, right? So the question is, does Confluent have a big enough name in the space to make it worthwhile to keep that marketing, you know, and that nomenclature around? I don't know. Because Red Hat was ginormous, right? Like, huge, right? Branding and whatnot. I remember people would always confuse Confluent with Conf luence. Yeah. When I would tell them I work at Confluent, they were like, oh, you do the wiki. Yeah, yeah, yeah. I've had that conversation more times than I would like to admit, as well. So I think WarpStream goes away quickly. I think Confluent sticks around for a while, a couple of years at least. And then we see where it goes from there. My take is that Flink is going to get significantly de- invested. As you said, it got so much R&D investment that I don't see IBM keeping it up. I guess they're smart enough to not decommission the product immediately. But I would be really surprised if they keep even 50% of the investment in terms of continuing development and stuff like that. Because, you know, there's a difference when you acquire a company for $11 billion, you're looking to pay that money off as fast as possible. And a new player like IBM, or sorry, a third-party viewer, if you look into Confluence financials, you have even an insider view. You know what's the cash cow. And you're going to bet everything on that. And anything that's not a cash cow and that's losing money, unless they really are able to sell you on the vision for that, you're probably not going to buy into. Agreed. Agreed. So the only way I see Flink surviving is if IBM sees an opportunity to, you know, go after, you know, Databricks and Snowflake, right, to compete with them directly if they want to, right? They could keep building Flink into a real competitor that way. They have the money. They have the resources. I don't know, though. I don't know what their take is on that. If that's a space they want to play in, do they want to compete there? Because, again, they've already got DB2 on the mainframes and all that, right? So maybe they just ditch Flink and I don't know. Yeah, that's more of a, I guess, strategic decision that somebody who has a full view can make. Yeah, or maybe, you know, maybe they run Flink on the main frame and being like, you know, oh, you want to migrate to Databricks? No, you've already got our mainframe, Mr. Big Bank. You know, we'll just run Flink on there for you. You can do everything you can do in Databricks, but with us now. That's a real possibility. That's a real possibility. That's why it's interesting. We don't have time to dive into this, but it's interesting, as you said, we're all looking for what are these big players, Snowflake Databricks, what are they going to do in regards to streaming? And in regards to the content acquisition now, I think it's even a more pressing time to answer that question from them . But it's also, yeah, sorry, go ahead. No, you too. It's also, it also comes back to you again, as long as you Kafka protocol compatible, right? So like they have Snowpipe over at Snowflake and, you know, Databricks has streaming as well. I don't think Snowpipe is kind of compatible. The key I think is going to be, is again, the way I see it is Kafka protocol is like TCP for the data plane. So as long as you've got compatibility with that, what's behind it, nobody really cares. Yeah, that's why I kind of foresee, and I think they should , some of these companies are going to, Snowflake almost bought Red Panda a year ago. But Red Panda is expensive because they raised a bunch from VCs, they're a more mature company. I think the next acquisition is probably going to be, I think, Stream Native, the Polestar guys who also have some Kafka expertise. I think they're going to get bought out by some of, by one of the big players. It's very possible. It's very possible. It could trigger a bit of a talent war, you know, where this purchase of Confluent, then suddenly everyone's like, oh, we're competing against IBM. If you're like Snowflake or Databricks, you've got so much funding and money behind you that you know you can compete against Confluent, who is smaller. Whereas if Confluent suddenly has IBM behind them, that's the 800-pound gorilla, right? Let me go on a fucking rant because I've been wanting to rant on this for a while. A year ago, when Snowflake almost bought Red Panda, I was pounding the table online saying it is so stupidly dead obvious for some of these companies to go into streaming. What these companies have on top of Confluent, and I think Confluent tried their strategy as well, is that when you have auxiliary revenue, meaning you're introducing a net new product line. So let's say Confluent is introducing Flink. They make all their money from Kafka, now they're going to make it from Flink. If Snowflake introduces streaming, they make all their money from analytics, from the database, now they're introducing streaming. When you're introducing that new product, this is net new revenue for you. And when you're a public company, the thing where public companies are kind of chained together by handcuffs is signaling to the market. They say, we're going to go at 30% revenue, and if we miss that, if we miss going by 30%, if we go by 28%, we're going to get severely punished. So their future revenue is really locked. You cannot do too much by changing the price or really just fiddling with it too much because you're risking a lot of value. You might get a lot of value raised. So that's why they cannot lower prices. That's why Confluent was so, I don't want to swear, but they got so screwed by Warp Steam. Not that Warp Steam was still hurting them per se, but the idea of a Warp Steam, the idea of some little guy coming and cutting you by the knees or by the Achilles heel and lowering the price so much where you know that you structurally cannot compete on that price because while you can probably be profitable at that price, if you have to lower the price, your future revenue projections would slow down so much that the market will completely obliterate your stock. And that's something that the management cannot do, the board doesn't want to do, the investors don't want to do. So they really got you by the Achilles heel. And I think that's why Confluent ultimately bought Warp Steam. I think that fear was just too big for them. And in the same way, Confluent could have been, or maybe they tried to be, or maybe they wanted to be, the Warp Steam or the Achilles heel to a Databricks or even to IBM. It's still the same example. Legacy vendors sell something for a very high price. For you, it's a brand new product. You can offer a much lower price and still be profitable and still be good with the market and everything and grow that and eat into their pie. So from that point of view, I always thought that sometimes like a snowflake, it doesn't take too much for a snowflake to hire a team of 10 Kafka experts, committers or whatever, or acquire a team and have them build out the Kafka service . I mean, most of it is in the open source anyway. And the real difficult things, which you saw in Confluent, the difficult thing of having a cloud system is having the control plane, having the billing, having all of the little stuff around like how do you deploy in the cloud? Well, how does this cloud work, et cetera? All these difficult little things and learning how to sell in a cloud-based way. That's a big investment. That was as big of an investment as it was to develop Kafka and Confluent, even probably bigger. Somebody like Snowflake has already solved this problem. So for them to introduce a new managed service on top of it , their only problem to solve is what is the service, how do I run it? And again, you don't need that many people to do it, especially if you're not trying to offer something very premium or extravagant. If you just want to offer the Kafka API, 10 people in a year will probably do it. Now with AI probably even less, less people, less time. So I agree with you in a lot of ways on that. And I think if this was three years ago, I would completely be 100% like, why on earth are you guys not doing your own Kafka or Kafka equivalent, right? Protocol compatible equivalent, right? For a Snowflake or whatever. I completely agree with you. The thing is, Kafka has become a bit like the mainframe these days. It's not very sexy anymore, right? It's critical infrastructure, like the mainframe. It's used everywhere. Everyone needs it, but it's not sexy. The sexy thing now is AI. So what you're seeing of Snowflake and Databricks, right, is, and it makes sense, is they're building AI services on top of their platforms now. So that's the next service they're offering, is their own AI, like AI on your data, right? So you can run models directly on your data that they host for you, right? That is what they're doing. I think if we were having this conversation three years ago or two years ago, I'd be like, before the real wave of AI agents and all this stuff started hitting, I'd 100% agree with you, right? Like, they should have done their own Kafka protocol equivalent service like three years ago. Nowadays, they probably should still do something, but it's going to go on the back burner because it's not the hot, sexy thing anymore. AI is the hot, sexy thing. So that's what they're building out, right? You've pointed it out correctly. What I see is every data infrastructure company is chasing the next 10x. That's what everyone is doing. The Kafka companies are chasing the next 10x. Confluent was chasing the next 10x with Flink and AI agents . And I assume Snowflake and Databricks are as well. And, yeah, that's what they do. I mean, every company has, you know, an amount of innovation tokens, and they can't really have too much stuff going on at the same time. But, again, I mean, in terms of just proper ROI, in terms of how much money you would put into something, how much it would give you back, I feel like it's such an obvious thing to do. But I understand why they're chasing the 10x. I'm not sure it pans out for them. And, you know, they have their own incentives to follow. I mean, again, I think it comes back to data gravity. You know, if you've got 99% of your corporate data in Snow flake, right, it makes sense for you to run a model on top of that, right? Because then it's trained exactly on your data set or Datab ricks, conversely, as well, right? Yeah, it's interesting. I mean, the other thing I find extremely frustrating about that situation is the fact that Databricks is still not a public company. I mean, I don't want to go off on a tangent, but the fact that they're a private company is just absolutely insane to me. Yeah, you know, anyways, that's a whole different discussion. Go on a little bit of a tangent. Give me a few sentences. I just, what was Databricks' last funding round? Series K or something like that. Yeah, like, that is just stupid. That shouldn't be allowed. Series L. Yeah, I feel like there should be a cap on funding rounds. Like, once you get to, like, D, that's it. You got, from the time you raise your Series D, you got two years to go public. After that, you're done. Like, there shouldn't be, you know, like, it's absolutely insane. Yeah. Like, Series K, that's absolutely bonkers. A, B, C, D, E. Like, could you imagine? Like, I hope they must be doing secondary offerings. Like, could you imagine? You're an early employee at Databricks, right? And you're, you know, you get your equity, right? And you're potentially sitting on $10, $20 million of equity, maybe more, right? Because of they're worth $100 billion, right? And you can't get it out of the company because you're not a public company. They must be doing secondaries to make some of these people whole. They must be. They must be. They must be. It's the 11th halfway. But, so there's that side of it. But then imagine, like, but even just, like, like, how are you, like, competing against a privately held company? Because they're privately held, they don't have to tell you anything. So, as a competitor, how do you compete? Like, it's really hard to compete up against that, right? Because you don't know what's going on. Like, everything you know is what you can suss out by talking to your customers. Oh, what are you doing with Databricks? What are you, like, because none of that, you know, none of the SEC filings. There's nothing. And it's just, it's just, and, like, $100 billion valuation , that's just crazy. Like, it's just crazy. Crazy that they're still not a public company. And I, yeah, I don't know. Like, their numbers must be, just be absolutely phenomenal. Because I, for the life of me, could not see investing in it. If I had, you know, a couple billion bucks and I was a VC investor, I could not see putting a Series K into a company . Like, that just seems crazy to me. Yeah, but at the end of the day, it's just evaluation and the revenue that matters, right? As an investor, you don't really care if it's Series Z or A . You only care about what money am I getting it into and what do I get into. Well, but you keep diluting, right? The more Series you run, you keep diluting. Diluting, yeah, but you can dilute in public markets as well. Sure, you absolutely can. But, like, yeah, it's just, yeah, it's interesting. It's really interesting. I just wanted to say that, I guess I don't want to hear your tangent on AI companies and their valuations. I can have a whole bunch of it. That's just, yeah, it's don't even get me started. I mean, I'll believe it when I see it. Let's put it that way. When I can see some revenue numbers and whatnot, I'll, you know, it'll be interesting. Again, AI is here. It's a good thing. It's got cool use cases. Don't get me wrong. It's real. It is helpful. It does add value is maybe the better way to describe it. It definitely adds value in a lot of situations. But some of these valuations are just, like, I don't know. Maybe I'll be wrong. Maybe we'll, you know, maybe OpenAI will, you know, go public at a trillion dollars. Who knows? Maybe I'll be wrong. But, like, it just, yeah. Well, it's a bit. It seems frothy to me. Let's put it that way. Definitely, yeah. I think that's a great place to end it before we go on another tangent. I think we'll have to save it for another podcast. Definitely, man. But, yeah, thank you so much for coming on, Justin. This was such a nice talk. So pleasant. Yeah, no, I had a lot of fun. Thank you so much. It's good catching up. It was a bit all over the place, but it was a lot of fun. You should do this again, man. Yeah, thanks. I'll see you again. Thanks for having me.
Created
March 30, 2026 09:52
-
-
Save stanislavkozlovski/3cd41999066e3316819885f20f7963ae to your computer and use it in GitHub Desktop.
A whisper turbo transcript of `IBM, Confluent Kafka, Mainframes and the 2026 Infra Startup Space` with Justin Manchester. https://youtu.be/yajOtZzSsGw
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment