Confluent, Inc. (CFLT) Earnings Call Transcript & Summary

Okay. We have Jay Kreps, who is CEO of Confluent, previously Principal Staff Engineer at LinkedIn.

That's true.

So tell us about the history of Confluent and Kafka, to start at the highest possible level. But -- and also, I got to say, some of you may know, I have a pre-letter degree and something that's not in finance, and I actually have been [indiscernible] Kafka at one point. So...

There you go. All right. All right. You've done your research.

I did. So go for it. Let's talk about the history.

Yes. So Confluent is about 7 years old as a company, but the open source technology, Kafka, actually predates the company. And so it was created by myself and my cofounders at LinkedIn. And the idea was really to focus on the side of the data problem that nobody really thinks as much about, which is data in motion. So people -- when we think about data infrastructure, we tend to think about storage and databases, where does the data go to sit, but at least our finding was if you really want us to take advantage of the data, how it flowed between applications, between systems, between data stores, how you were able to act and react off of what was happening right now, that was kind of like half the problem. But it wasn't the half that really had much -- there wasn't much help with that half. And so whereas, like in the database world, there's decades of research from every computer science department and huge commercial investment, in -- for data in motion, there was just kind of some half-baked tools that would help with parts of the problem and nothing really general purpose. And so for LinkedIn, that didn't really make sense. This is a digital company that wanted to be very smart about the use of data and be able to act on it in all parts of the company. And so we started to think about, hey, what would that look like if you try to build an infrastructure layer that would let you really work with data as it occurred and as it arrived and if you let that flow across all the parts of organization. And what we came up with was this idea of thinking of data not as something that kind of sits. Like in the data world, you would have your data warehouse, which is kind of what it sounds, right, it's like the warehouse full of all the data. You would think of it as kind of like a stream, something that flows between things and with little...

[indiscernible] a bowling alley...

Yes, that's right. A little -- the river goes off and splits off to all the systems that would want it. But it's something that's always kind of moving and that you're reacting to as it occurs. And so that was, yes, that was kind of the underlying big idea. This was an idea that had existed a little bit in academia, in computer science, but it wasn't something that really much practical systems had been built around. And we built Kafka to really be that basis to capture all these streams and do it at scale. And we released it as open source originally to resounding silence because people had no idea what we were talking about. But over time, that became really a foundational layer in the biggest tech companies in the world that started to build around that new paradigm of data. And then we left in 2014 to go really turn that into a product and take it out to the rest of the world. We felt like that could be as applicable in every company as it was in these tech companies.

So let's be really concrete about what were you -- what was the problem you were solving. So I mean, it seems some of the things you're saying seems sort of, obviously, oh, yes, real-time day-to-day motion, that's the world we live in. It's like, okay. But what's happening when you were at LinkedIn? What couldn't you do with the stuff that you had? And then what did you say, here's what we got to do and here's how we fix it?

Yes. So LinkedIn, like a lot of companies, had little chunks of software that did part of the problem. And each of those parts had data about its operation. But a lot of the intelligent things you would have wanted needed to know about what was happening across. And we had that, but the access to it was kind of confined to these "end of the day" batch systems, like the data warehouse or the Hadoop cluster. And it didn't really make sense. You think about this kind of very dynamic digital product that's generating data all the time. People are interacting with it all the time. The operations of that business is very real-time. You would expect, like the real world, you could act on things that were happening right now and not have to wait to load everything into a data warehouse. And we were finding that the solution to that was a ton of work. We were just having large teams of software engineers that would build these pointwise integrations, from one thing to another. And it was very hard to build things that were reliable, that kind of operated quickly like that. And we -- whenever you have that situation where you're kind of building the same thing over and over again in kind of a half-baked way, that's an opportunity for the infrastructure to take over more and try and do it better. And we felt that was a common problem across all companies, that they needed that.

So Kafka is of -- has got some new structures to it, and again, just to be clear, obviously, the Confluent commercial business built around open source Kafka. So Kafka still is a messaging technology. It's a way of sending relatively small packets of data from one place to another, historically, from one place to one other place. But those messaging technologies with it, RabbitMQ and the various different messaging technologies that were built by everyone, from WebSphere and TIBCO, these have been around for a very long time. What's -- so you could do this but in a more primitive way, let's say. What was the insight, what was the difference...

Yes. I think that's right. So if you think about technology that works with data as it moves, these kind of integration technologies, there was a set of kind of MQs. And that's one thing that this new area would overlap with. The other thing that was out there was maybe some of the ETL products, like the Informaticas of the world that would kind of pick up data and move it in bulk, right? The other thing that would be out there would be things like a MuleSoft that might integrate more kind of SaaS systems and then a lot of other products, which would solve little bits of these areas. But there was nothing that could kind of do it all. And you would say, well, does that matter, why do you need one thing that does it all. Well, think about it this way. Let's say you're a retailer and you have sales that are happening continuously in all the different stores that you've got. What needs that sales data? Well, it turns out a lot of things do, right? Retail is kind of a business that happens in reaction to what products they're selling and what's being shipped and arriving. There's going to be hundreds of different systems that need to tap into that and use it in different ways. And so if you have to build kind of custom integrations with different products for each of these solutions, it's very complicated and it's very slow, and it's very brittle. And each of these prior solutions had limitations. They weren't scalable. They weren't real-time. They were very low levels. So it was a lot of work to take advantage of them. It looks a little bit like the storage world before databases, where you had a lot -- it was like you could have stored data, but you had a lot of low-level solutions that would do parts of things. And relational databases really kind of brought that together and came up with something that was more general, that could make it much easier to build applications in that domain. And that was what we felt the opportunity was, we'll say, hey, make it so that in that retailer, you could have this stream of everything that's selling. And anything in the organization that wants to react to that, that wants to tap into it, that wants to use that in a smart way can do that and make that as easy as working with kind of static stored data. And in a way, it's kind of an obvious thing. You would almost say why didn't it always work that way. But I think the pressure that caused this is just as companies have more software, as the parts have to interrelate more, it becomes more and more pressing to be able to do that well.

Right. So it's real-time, it's data in motion. And I feel like what you're describing in terms of different sources of data being used by many different people, the evidence is part of what's sometimes called "pub/sub," right?

Yes, yes.

So that makes it a lot -- I think that makes it a lot more flexible in terms of the...

Yes. Yes, the idea is any part of the business, application, some other system, can kind of publish out what data it has. And then any other system in the organization can subscribe to that stream and can react to it and do what it wants with it. And this is part of what helps the scale to a big complicated organization with lots of data is. Every part of the organization doesn't have to build integration with every other part. They just need to say what they have got and what they want, right, which is a much simpler problem to solve.

So I think you had a technical innovation that came from frustrations around not being able to achieve certain things, although certain parts of the technology were already there. Was there -- what's taking place in terms of the world in terms of the use cases that are emerging in this faster digital world that necessitates this? Why do we need this now? What are the range of use cases? And by the way, so full disclosure, KeyBanc is a customer. And I'll get -- I'll mention the one example I know we're talking about. Recently, we had an Adobe Stack, and when certain things take place relative to how we want to either reach new or existing customers, that data is already always published to Confluent Kafka and then Adobe subscribes to it. And that pushes out notifications either to existing or prospective customers.

Yes. Yes.

And that's done in real-time. So what about things like that?

Yes. And that's a perfect example. If you think about kind of broadly what's happening, the early adoption of software was little bits of software here and there that was kind of disconnected, and it didn't really need to integrate with everything else. What's changed is now a lot more of the business is covered in software, and increasingly, that software has to be a lot smarter and integrate a lot more signals of what's happening elsewhere so that things work coherently. And that's particularly true in parts of the company that interact with customers. It's particularly true in parts of the company that actually run the operations of the business, produce the goods and services. Those things are inherently integrated systems that have to all work together. And that requires having an up-to-date view of what's happening. It requires being able to tap into the data around the company and work on it in real-time. And so I think that's what's driven the increase and need in this spaces, is, hey, more software, more data, more integration and then more pressure from customers, from competitors, to really put that all together in a smart way.

I want to switch over to -- we bring up the macro question [indiscernible] on old calls, it's your business, you're aware of the environment. And then in the investment community, this is where we start pretty frequently. We just completed our round of midyear surveys. We do a VaR survey every quarter. We do a CIO survey every other quarter. And data analytics came out really high. It always comes up pretty high, but it came out higher. And one of the things that we felt was really interesting about that is that if we look back to 2020, data -- a lot of data analytics projects seem to slow. My sense is there's -- that there's less of that slowing now. How do you perceive what's going on in the macro environment relative to the projects that you're seeing right now?

Yes. I would speak mostly to our own business. There's a large variety of things in the data world, and they are different products and behave differently. What we saw was really continued strong demand and enthusiasm. We didn't see fewer projects in this space that would use the technology. We didn't see projects be kind of shelved, which sometimes, in tighter times, you can see. We did see more scrutiny on deals, so just like a little more scrutiny on TCO, payoff times.

Does that mean longer deal cycles?

Yes, it did in certain instances for us. I wouldn't say it was a broad trend in every deal, but certainly, kind of across the board, not limited to one part of the economy, but we did see a handful of deals that just moved slower than we would have expected. And particularly, we saw more, just analysis on how money is being spent. And the reasons were a little different in, say, a big European retailer than they would be in a smaller private tech company, but they're both thinking about how money is being spent for different reasons a little bit more closely. We felt like we did pretty well in that dimension. We have a couple of advantages in this respect. We serve -- we tend to serve production use cases, so things that would help run the business in some way. And I think those tend to come out pretty well-optimized and have a strong story for how the business is benefiting, otherwise you wouldn't have fund it to begin with. And I think that helps us kind of get through that. And then we, over the years, we have built, I think, a very strong TCO story for the product, of why do you want this, why would you get this versus just using the open source. That's something where we've gotten much more quantitative about what the payoff is. We have a lot more proof points to show customers. And that's -- really the thing that helps that the most is our cloud offering, which makes this a much easier way to kind of consume these capabilities and has a much stronger TCO for most customers than kind of try to do it themselves.