Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: Tired of slow database performance and bottlenecks on MySQL or PostgresSQL when using Amazon RDS or Aurora? How’d you like to reduce query response times by ninety percent? Better yet, how would you like to get me to pronounce database names correctly? Join customers like Zscaler, Intel, Booking.com, and others that use OtterTune’s artificial intelligence to automatically optimize and keep their databases healthy. Go to ottertune dot com to learn more and start a free trial. That’s O-T-T-E-R-T-U-N-E dot com.

Corey: Welcome to Screaming in the Cloud, I’m Corey Quinn, and this promoted guest episode is brought to us by our friends at Redpanda, which I’m thrilled about because I have a personal affinity for companies that have cartoon mascots in the form of animals and are willing to at least be slightly creative with them. My guest is Alex Gallego, the founder and CEO over at Redpanda. Alex, thanks for joining me.

Alex: Corey, thanks for having me.

Corey: So, I’m not asking about the animal; I’m talking about the company, which I imagine is a frequent source of disambiguation when you meet people at parties and they don’t quite understand what it is that you do. And you folks are big in the data streaming space, but data streaming can mean an awful lot of things to an awful lot of people. What is it for you?

Alex: Largely it’s about enabling developers to build applications that can extract value of every single event, every click, every mouse movement, every transaction, every event that goes through your network. This is what Redpanda is about. It’s like how do we help you make more money with every single event? How do we help you be more successful? And you know, happy to give examples in finance, or IoT, or oil and gas, if it’s helpful for the audience, but really, to me, it’s like, okay, if we can give you the framework in which you can build a new application that allows you to extract value out of data, every single event that’s going through your network, to me, that’s what a streaming is about. It large, it’s you know, data contextualized with a timestamp and largely, a sort of a database of event streaming.

Corey: One of the things that I find curious about the space is that usually, companies wind up going one of two directions when you’re talking about data streaming. Either there, “Oh, just send it all to us and we’ll take care of it for you,” or otherwise, it’s a, great they more or less ship something that you’ve run in your own environment. In the olden days of data centers, that usually resembled a box of some sort. You’re one of those interesting split-the-difference companies where you offer both models. Do you find that one of those tends to be seeing more adoption these days or that there’s an increasing trend toward one direction or the other?

Alex: Yeah. So, right now, I think that to me, the future of all these data-intensive products—whether you’re a database or a streaming engine—will, because simply of cost of networks transferred between the hybrid clouds and your accounts, sending a gigabyte a second of data between, let’s say, you know, your data center and a vendor, it’s just so expensive that at some point, from just a cost perspective, like, running the infrastructure, it’s in the millions of dollars. And so, running the data inside your VPC, it’s sort of the next logical evolution of how we’ve used to consume services. And so, I actually think it’s just the evolution: people would self-host because of costs and then they would use services because of operational simplicity. “I don’t want to spend team skills and time building this. I want to pay a vendor.”

And so, BYOC, to be honest—which is what we call this offering—it was about [laugh] sidestepping the costs and of being stuck in the hybrid clouds, whether it’s Google or Amazon, where you’re paying egress and ingress costs and it’s just so expensive, in addition to this whole idea of data residency or data sovereignty and privacy. It’s like, yeah, why not both? Like, if I’m an engineer, I want low latency and I don’t want to pay you to transfer this thing to the next rack. I mean, my computer’s probably, like, you know, a hundred feet away from my customer's computer. Like, why [laugh] way is that so complicated? So, you know, my view is that the future of data-intensive products will be in this form of where it—like, data planes are actually owned by companies, and then you offer that as a Software as a Service.

Corey: One of the things that catches an awful lot of companies with telemetry use cases—or data streaming as another example of that—by surprise when they start building their own cloud-hosted offering is that they’re suddenly seeing a lot more cross-AZ data charges than they would have potentially expected. And that’s because unlike cross-region or the really expensive version of this with egress, it’s a penny in and a penny out per gigabyte in most of AWS regions. Which means that that isn’t also bound strictly to an AWS organization. So, you have customers co-located with you and you’re starting to pay ingress charges on customers throwing their data over to you. And, on some level, the most economical solution for you is well, we’re just going to put our listeners somewhere else far away so that we can just have them pay the steep egress fee but then we can just reflect it back to ourselves for free.

And that’s a terrible pattern, but it’s a byproduct of the absolutely byzantine cross-AZ data transfer pricing, in fact, all of the data transfer pricing that is at least AWS tends to present. And it shapes the architectural decisions you make as a result.

Alex: You know, as a user, it just didn’t make sense. When we launched this product, the number of people that says like, “Why wouldn’t your charge for, you know, effectively renting [unintelligible 00:05:14], and giving a markup to your customers?” That’s we don’t add any value on that, you know? I think people should really just pay us for the value that we create for them. And so, you know, for us competing with other companies is relatively easy.

Competing with MSK is it’s harder because MSK just has this, you know, muscle where they don’t charge you for some particular network traffic between you. And so, it forces companies like us that are trying to be innovative in the data space to, like, put our services in that so that we can actually compete in the market. And so, it’s a forcing function of the hybrid clouds having this strong muscle of being able to discount their services in a way that companies just simply don’t have access to. And then, you know, it becomes—for the others—latency and sovereignty.

Corey: This is the way that effectively all of AWS has first-party offerings of other things go. Replication traffic between AZs is not chargeable. And when I asked them about that, they say, “Oh, yeah. We just price that into the cost of the service.” I don’t know that I necessarily buy that because if I try and run this sort of thing on top of EC2, it would cost me more than using their crappy implementation of it, just in data transfer alone for an awful lot of use cases.

No third party can touch that level of cost-effectiveness and discounting. It really is probably the clearest example I can think of actual anti-competitive behavior in the market. But it’s also complex enough to explain, to, you know, regulators that it doesn’t make for exciting exposés and the basis for lawsuits. Yet. Hope springs eternal.

Alex: [laugh]. You know—okay, so here is how—if someone is listening to this podcast and is, like, “Okay, well, what can I do?” For us, S3 is the answer. S3 is basically you need to be able to lean in into S3 as a way of replication across [AZ 00:06:56], you need to be able to lean into S3 to read data. And so actually, when I wrote, originally, Redpanda, you know, it’s just like this C++ thing using [unintelligible 00:07:04], geared towards super low latency.

When we moved it into the cloud, what we realized is, this is cost prohibitive to run either on EBS volumes or local disk. I have to tier all the storage into S3, so that I can use S3’s cross-AZ network transfer, which is basically free, to be able to then bring a separate cluster on a different AZ, and then read from the bucket at zero cost. And so, you end up really—like, there are fundamental technical things that you have to do to just be able to compete in a way that’s cost-effective for you. And so, in addition to just, like, the muscle that they can enforce on the companies is—it—there are deep implications of what it translates to at the technical level. Like, at the code level.

Corey: In the cloud, more than almost anywhere else, it really does become apparent that cost and architecture are fundamentally the same thing. And I have a bit of an advantage here in that I’ve seen what you do deployed at least one customer of mine. It’s fun. When you have a bunch of logos on your site, it’s, “Hey, I recognize some of those.” And what I found interesting was the way that multiple people, when I spoke to them, described what it is that you do because some of them talked about it purely as a cost play, but other people were just as enthusiastic about it being a means of improving feature velocity and unlocking capabilities that they didn’t otherwise have or couldn’t have gotten to without a whole lot of custom work on their part. Which is it? How do you view what it is that you’re bringing to market? Is it a cost play or is it a capability story?

Alex: From our customer base, I would say 40% is—of our customer base—is about Redpanda enabling them to do things that they simply couldn’t do before. An example is, we have, you know, a Fortune 100 company that they basically run their hedge trading strategy on top of Redpanda. And the reason for that is because we give them a five-millisecond average latency with predictable flight latencies, right? And so, for them, that predictability of Redpanda, you know, and sort of like the architecture that came about from trying to invent a new storage engine, allows them to throw away a bunch of in-house, you know, custom-built pub/sub messaging that, you know, basically gave them the same or worse latency. And so, for them, there’s that.

For others, I think in the IoT space, or if you have flying vehicles around the world, we have some logos that, you know, I just can’t mention them. But they have this, like, flying computers around the world and they want to measure that. And so, like, the profile of the footprint, like, the mechanical footprint of being able to run on a single Pthread with a few megs of memory allows these new deployment models that, you know, simply, it’s just, it’s not possible with the alternatives where let’s say you have to have, you know, like, a zookeeper on the schema registry and an HTTP proxy and a broker and all of these things. That simply just, it cannot run on a single Pthread with a few megs of memory, if you put any sort of workload into that. And so, it’s like, the computational efficiencies simply enable new things that you couldn’t do before. And that’s probably 40%. And then the other, it’s just… money was really cheap last year [laugh] or the year before and I think now it’s less cheap [unintelligible 00:10:08] yeah.

Corey: Yeah, I couldn’t help but notice that in my own business, too. It turns out that not giving a shit about the AWS bill was a zero-interest-rate phenomenon. Who knew?

Alex: [laugh]. Yeah, exactly. And now people [unintelligible 00:10:17], you know, the CIOs in particular, it’s like, help. And so, that’s really 60%, and our business has boomed since.

Corey: Yeah, one thing that I find interesting is that you’ve been around for only four years. I know that’s weird to say ‘only,’ but time moves differently in tech. And you’ve started showing up in some very strange places that I would not have expected. You recently—somewhat recently; time is, of course, a flat circle—completed $100 million Series C, and I also saw you in places where I didn’t expect to see you in the form of, last week, one of your large competitor's earnings calls, where they were asked by an analyst about an unnamed company that had raised $100 million Series C, and the CEO [unintelligible 00:11:00], “Oh, you’re probably talking about Redpanda.” And then they gave an answer that was fine.

I mean, no one is going to be on an earnings call and not be prepared for questions like that and to not have an answer ready to go. No one’s going to say, “Well, we’re doomed if it works,” because I think that businesses are more sophisticated than that. But it was an interesting shout-out in a place where you normally don’t see competitors validate that you’re doing something interesting by name-checking you.

Alex: What was fundamentally interesting for me about that, is that I feel that as an investor, if you’re putting you know, 2, 3, 4, or $500 million check into a public position of a company, you want to know, is this money simply going to make returns? That’s basically what an investor cares about. And so, the reason for that question is, “Hey, there’s a Series C startup company that now has a bunch of these Fortune 2000 logos,” and you know, when we talked to them, like, their customer [unintelligible 00:11:51] phenomena, like, why is that the case? And then, you know, our competitor was forced to name, you know, [laugh] a single win. That’s as far as I remember it. We don’t know of any additional customers that have switched to that.

And so, I think when you have, like, you know, your win rate is above, whatever, 95%, 97% ratio, then I think, you know, they’re just sort of forced to answer that. And in a way, I just think that they focus on different things. And for me, it was like, “Okay, developer, hands on keyboard, behind the terminal, how do I make you successful?” And that seems to have worked out enough to be mentioned in the earnings call.

Corey: On some level, it’s a little bit of a dog-and-pony show. I think that as companies had a certain point of scale, they feel that they need to validate what they’re doing to investors at various points—which is always, on some level, of concern—and validate themselves to analysts, both financial—which, okay, whatever—and also, industry analysts, where they come with checklists that they believe is what customers want and is often a little bit off of the mark. But the validation that I think that matters, that actually determines whether or not something has legs is what your customers—you know, people paying you money for a thing—have to say and what they take away from what you’re doing. And having seen in a couple of cases now myself, that usage of Redpanda has increased after initial proofs of concept and putting things on to it, I already sort of know the answer to this, but it seems that you also have a vibrant community of boosters for people who are thrilled to use the thing you’re selling them.

Alex: You know, Jumptraders recently posted that there was a use case in the new stack where they, like, put for the most mission-critical. So, for those of you that listening, Jumptraders is financial company, and they’re super technical company. One of, like, the hardest things, they’ll probably put your [unintelligible 00:13:35] your product through some of the most rigorous testing [unintelligible 00:13:38]. So, when you start doing some of these logos, it gives confidence. And actually, the majority of our developers that we get to partner with, it was really a friend telling a friend, for [laugh] the longest time, my marketing department was super, super small.

And then what’s been fun, some, like, really different use case was the one I mentioned about on this, like, flying vehicles around the world. They fly both in outer space and in airplanes. That was really fun. And then the large one is when you have workloads at, like, 14-and-a-half gigabytes per second, where the alternative of using something like Kinesis in the case of Lacework—which, you know, they wrote a new stack article about—would be so exorbitantly expensive. And so, in a way, I think that, you know, just trying to make the developers successful, really focusing, honestly, on the person who just has to make things work. We don’t—by the time we get to the CIO, really the champion was the engineer who had to build an application. “I was just trying to figure it out the whack-a-mole of trying to debug alternative systems.”

Corey: One of the, I think, seductive problems with your entire space is that no one decides day one that they’re going to implement a data streaming solution for a very scaled-out, high-traffic site. The early adoption is always a small thing that you’re in the process of building. And at that scale at that speed, it just doesn’t feel like it’s that hard of a problem because scale introduces its own unique series of challenges, but it’s often one that people only really find out themselves when the simple thing that works in theory but not in production starts to cause problems internally. I used to work with someone who was a deeply passionate believer in Apache Kafka to a point where it almost became a problem, just because their answer to every problem—it almost didn’t matter if it was, “How do we get more coffee this morning?”—Kafka would be the answer for all of it.

And that’s great, but it turned out, they became one of these people that borderline took on a product or a technology as their identity. So, anything that would potentially take a workload away from that, I got a lot of internal resistance. I’m wondering if you find that you’re being brought in to replace existing systems or for completely greenfield stuff. And if the former, are you seeing a lot of internal resistance to people who have built a little niche for themselves?

Alex: It’s true, the people that have built a career, especially at large banks, were a pretty good fit for, you know, they actually get a team, they got a promotion cycle because they brought this technology and the technology sort of helped them make money. I personally tend to love to talk to these people. And there was a ca—to me, like, technically, let’s talk about, like, deeply technical. Let me help you. That obviously doesn’t scale because I can’t have the same conversation with ten people.

So, we do tend to see some of that. Actually, from our customers' standpoint, I would say that the large part of our customer base, you know, if I’m trying to put numbers, maybe 65%, I probably rip and replace of, you know, either upstream Apache Software or private companies or hosted services, et cetera. And so, I think you’re right in saying, “Hey, that resistance,” they probably handled the [unintelligible 00:16:38], but what changed in the last year is that the CIO now stepped in and says, “I am going to fire all of you or you have to come up with a $10 million savings. Help me.” [laugh]. And so, you know, then really, my job is to help them look like a hero.

It’s like, “Hey, look, try it tested, benchmark it in your with your own workload, and if it saves you money, then use it.” That’s been, you know, to sort of super helpful kind of on the macroeconomic environment. And then the last one is sometimes, you know, you do have to go with a greenfield, right? Like, someone has built a career, they want to gain confidence, they want to ask you questions, they want to trust you that you don’t lose data, they want to make sure that you do say the things that you want to say. And so, sometimes it’s about building trust and building that relationship.

And developers are right. Like, there’s a bunch of products out there. Like, why should I trust you? And so, a little easier time, probably now, that you know, with the CIOs wanting to cut costs, and now you have an excuse to go back to the executive team and say, “Look, I made you look smart. We get to [unintelligible 00:17:35], you know, our systems can scale to this.” That’s easy. Or the second one is we do, you know, we’ll start with some side use case or a greenfield. But both exists, and I would say 65% is probably rip-outs.

Corey: One question, I love to, I wouldn’t call it ambush, but definitely come up with, the catches some folks by surprise is one of the ways I like to sort out zealots from people who are focused on business problems. Do have an example of a data streaming workload for which Redpanda would not be a great fit?

Alex: Yeah. Database-style queries are not a fit. And so, think that there was a streaming engine before there was trying to build a database on top of it, and, like—and probably it does work in some low volume of traffic, like, say 5, 10 megabytes per second, but when you get to actual large scale, it just it doesn’t work. And it doesn’t work because but what Redpanda is, it gives you two properties as a developer. You can add data to the end or you can truncate the head, right?

And so, because those are your only two operations on the log, then you have to build this entire caching level to be able to give this database semantics. And so, do you know, I think for that the future isn’t for us to build a database, just as an example, it’s really to almost invert it. It’s like, hey, what if we make our format an open format like Apache Iceberg and then bring in your favorite database? Like, bring in, you know, Snowflake or Athena or Trina or Spark or [unintelligible 00:18:54] or [unintelligible 00:18:55] or whatever the other [unintelligible 00:18:56] of great databases that are better than we are, and doing, you know, just MPP, right, like a massively parallelizable database, do that, and then the job for us, for [unintelligible 00:19:05], let me just structure your log in a way that allows you to query, right? And so, for us, when we announced the $100 million dollar Series C funding, it’s like, I’m going to put the data in an iceberg format so you can go and query it with the other ten databases. And there are a better job than we are at that than we are.

Corey: It’s frankly, refreshing to see a vendor that knows where, okay, this is where we start and this is where we stop because it just seems that there’s been an industry-wide push for a while now to oh, you built a component in a larger system that works super well. Now, expand to do everything else in the architectural diagram. And you suddenly have databases trying to be network transport layers and queues trying to be data warehouses, and it just doesn’t work that way. It just it feels like oh, this is a terrible approach to solving this particular problem. And what’s worse, from my mind, is that people who hadn’t heard of you before look at you through this lens that does not put you in your best light, and, “Oh, this is a terrible database.” Well, it’s not supposed to be one.

Alex: [laugh].

Corey: But it also—it puts them off as a result. Have you faced pressure to expand beyond your core competency from either investors or customers or analysts or, I don’t know, the voices late at night that I hear and I assume everyone else does, too?

Alex: Exactly. The 3 a.m. voice that I have to take my phone and take a voice note because it’s like, I don’t want to lose this idea. Totally. For us. I think there’s pressures, like, hey, you built this great engine. Why don’t you add, like, the latest, you know, soup de jour in systems was like a vector database.

I was like, “This doesn’t even make any sense.” For me, it’s, I want to do one thing really well. And I generally call it internally, ‘the ring zero.’ It’s, if you think of the internet, right, like, as a computer, especially with this mode to what we talked about earlier in a BYOC, like, we could be the best ring zero, the best sort of like, you know, messaging platform for people to build real-time applications. And then that’s the case and there’s just so much low-hanging fruit for us.

Like, the developer experience wasn’t great for other systems, like, why don’t we focus on the last mile, like, making that developer, you know, successful at doing this one thing as opposed to be an average and a bunch of other a hundred products? And until we feel, honestly, that we’ve done a phenomenal job at that—I think we still have some roadmap to get there—I don’t want to expand. And, like, if there’s pressure, my answer is, like… look, the market is big enough. We don’t have to do it. We’re still, you know, growing.

I think it’s obviously not trivial and I’m kind of trivializing a bunch of problems from a business perspective. I’m not trying to degrade anyone else. But for us, it’s just being focused. This is what we do well. And bring every other technology that makes you successful. I don’t really care. I just want to make this part well.

Corey: I think that that is something that’s under-appreciated. I feel like I should get over at one point to something that’s been nagging at the back of my mind. Some would call it a personal attack and I suppose I’ll let them, but what I find interesting is your background. Historically, you were a distributed systems engineer at very large scale. And you apparently wrote the first version of Redpanda yourself in—was it C or C++?

Alex: C++.

Corey: Yeah. And now you are the CEO of a company that is clearly doing very well. Have you gotten the hell out of production yet? The reason I ask this is I have worked in a number of companies where the founder was also the initial engineer and then they invariably treated main as their feature branch and the rest of us all had to work around them to keep them from, you know, destroying everything we were trying to build around us, due to missing context. In other words, how annoyed with you are your engineers on any given afternoon?

Alex: [laugh]. Yeah. I would say that as a company builder now, if I may say that, is the team is probably the thing I’m the most proud of. They’re just so talented, such good [unintelligible 00:22:47] of humans. And so—group of humans—I stopped coding about two years ago, roughly.

So, the company is four-and-a-half years old, really the first two-and-a-half years old, the first one, two years, definitely, I was personally putting in, like, tons and tons of hours working on the code. It was a ton of fun. To me, one of the most rewarding technical projects I’ve ever had a chance to do. I still read pull requests, though, just so that when I have a conversation with a technical leader, I don’t be, like, I have no clue how the transactions work. So, I still have to read the code, but I don’t write any more code and my heart was a little broken when my dev prod team removed my write access to the GitHub repo.

We got SOC2 compliance, and they’re like, “You can’t have access to being an admin on Google domains, and you’re no longer able to write into main.” And so, I think as a—I don’t know, maybe my identity—myself identity is that of a builder, and I think as long as I personally feel like I’m building, today, it’s not code, but you know, is the company and [unintelligible 00:23:41] sort of culture, then I feel okay [laugh]. But yeah, I no longer write code. And the last story on that, is this—an engineer of ours, his name is [Stefan 00:23:51], he’s like, “Hey, so Alex wrote this semaphore”—this was actually two days ago—and so they posted a video, and I commented, I was like, “Hey, this was the context of semaphore. I’m sorry for this bug I caused.” But yeah, at least I still remember some context for them.

Corey: What’s fun is watching things continue to outpace and outgrow you. I mean, one of the hard parts of building a company is the realization that every person you hire for a thing that’s now getting off of your plate is better at that thing than you are. It’s a constant experience of being humbled. And at some point, things wind up outpacing you to the point where, at least in my case, I’ve been on calls with customers and I explained how we did some things and how it worked and had to be corrected by my team of, “Well. That used to be true, however…” like, “Oh, dear Lord. I’m falling behind.” And that’s always been a weird feeling for me.

Alex: Totally. You know, it’s the feeling of being—before I think I became a CEO, I was a highly comped engineer and did a competent, to the extent that it allowed me to build this product. And then you start doing all of these things and you’re incompetent, obviously, by definition because you haven’t done those things and so there’s like that discomfort [laugh]. But I have to get it done because no one else wants to do, whatever, like say, like, you know, rev ops or marketing or whatever.

And then you find somebody who’s great and you’re like, oh my God, I was like, I was so poor tactically at doing this thing. And it’s definitely humbling every day. And it’s almost it’s, like, gosh, you’re just—this year was kind of this role where you’re just, like, mediocre at, like, a whole lot of things as a company, but you’re the only person that has to do the job because you have the context and you just have to go and do it. And so, it’s definitely humbling. And in some ways, I’m learning, so for me today, it’s still a lot of fun to learn.

Corey: This is a little more in the weeds, I suppose, but I always love to ask people these questions. Because I used to be naive, which meant that I had hope and I saw a brighter future in technology. I now know that was all a lie. But I used to believe that out there was some company whose internal infrastructure for what they’d built was glorious and it would be amazing. And I knew I would never work there, nor what I want to, because when everything’s running perfectly, all I can really do is mess that up; there’s no way to win and a bunch of ways to lose.

But I found that place doesn’t exist. Every time I talk to someone about how they built the thing that they built and I ask them, “If you were starting over from scratch, what would you do differently?” The answer often distills down to, “Oh, everything.” Because it’s an organically evolving system that oh, yeah, everything’s easier the second time. At least you get to find new failure modes go in that way. When you look back at how you designed it originally, are there any missteps that you could have saved yourself a whole lot of grief by not making the first time?

Alex: Gosh, so many things. But if I were to give Hollywood highlights on these things, something that [unintelligible 00:26:35] is, does well is exposing these high-level data types of, like, streams, and lists and maps and et cetera. And I was like, “Well, why couldn’t streams offer this as a first-class citizen?” And we got some things well which I think would still do, like the whole [thread recorder 00:26:49] could—like, the fundamentals of the engine I will still do the same. But, you know, exposing new programming models earlier in the life of the product, I think would have allowed us to capture even more wildly different use cases.

But now we kind of have this production engine, we have to support Fortune 2000, so you know, it’s kind of like a very delicate evolution of the product. Definitely would have changed—I would have added, like, custom data types upfront, I would have pushed a little harder on I think WebAssembly than we did originally. Man, I could just go on for—like, [added detail 00:27:21], I would definitely have changed things. Like, I would have pressed on the first—on the version of the cloud that we talked about early on, that as the first deployment mode. If we go back through the stack of all of the products you had, it’s funny, like, 11 products that are surfaced to the customers to, like, business lines, I would change fundamental things about just [laugh], you know, everything else. I think that’s maybe the curse of the expert. Like, you know, you could always find improvements.

Corey: Oh, always. I still look back at my career before starting this place when I was working in a bunch of finance companies, and—I’ll never forget this; it was over a decade ago—we were building out our architecture in AWS, and doing a deal with a large finance company. And they said, “Cool, where’s your data center?” And I said, “Oh, it’s AWS.” And they said, “Ha ha ha ha. Where’s your data center?”

And that was oh, okay, great. Now, it feels like if that’s their reaction, they have not kept pace with the times. It feels it is easier to go to a lot of very serious enterprises with very serious businesses and serious workload concerns attendant to those and not get laughed out of the room because you didn’t wind up doing a multi-million dollar data center build out that, with an eye toward making it look as enterprise-y as possible.

Alex: Yeah. Okay, so here’s, I think, maybe something a little bit controversial. I think that’s true. People are moving to the cloud, and I don’t think that that idea, especially when we go when we talk to banks, is true. They’re like, “Hey, I have this contract with one of the hybrid clouds.”—you know, it’s usually with two of them, and then you’re like—“This is my workload. I want to spend $70 million or $100 million. Who could give me the biggest discount?” And then you kind of shop it around.

But what we are seeing is that effectively, the data transfer costs are so expensive and running this for so much this large volume of traffic is still so, so expensive, that there is an inverse [unintelligible 00:29:09] to host from some category of the workload where you don’t have dynamism. Actually hosted in your data center is, like, a huge boom in terms of cost efficiencies for the companies, especially where we are and especially in finances—you mentioned that—if you’re trying to trade and you have this, like, steady state line from nine to five, whatever, eight to four, whenever the markets open, it’s actually relatively cost-efficient because you can measure hey, look, you know, the New York Stock Exchange is 1.5 gigabytes per second at market close. Like, I could provision my hardware to beat this. And like, it’ll be that I don’t need this dynamism that the cloud gives me.

And so yeah, it’s kind of fascinating that for us because we offered the self-hosted Redpanda which can adapt to super low latencies with kernel parameter tuning, and the cloud due to the tiered storage, we talked about S3 being [unintelligible 00:29:52] to, so it’s been really fun to participate in deployments where we have both. And you couldn’t—they couldn’t look more different. I mean, it’s almost looks like two companies.

Corey: One last question before we wind up calling it an episode. I think I saw something fly by on Twitter a while back as I slowly returned to the platform—no, I’m not calling it X—something you’re doing involving a scholarship. Can you tell me a bit more about that?

Alex: Yeah. So, you know, I’m a Latino CEO, first generation in the States, and some of the things that I felt really frustrated with, growing up that, like, I feel fortunate because I got to [unintelligible 00:30:25] that is that, you know, people were just—that look like me are probably given some bullshit QA jobs, so like, you know, behemoth job, I think, for a bank. And so, I wanted to change that. And so, we give money and mentorship to people and we release all of the intellectual property. And so, we mentor someone—actually, anyone from underrepresented backgrounds—for three months.

We give then, like, 1200 bucks a month—or 1500, I can’t remember—mentorship from our top principal level engineers that have worked at Amazon and Google and Facebook and basically the world’s top companies. And so, they meet with them one hour a week, we give them money, they could sit in the couch if they want to. No one has to [unintelligible 00:31:06]. And all we’re trying to do is, like, “Hey, if you are part of this group, go and try to build something super hard.” [laugh].

And often their minds, which is great, and they’re like, “I want to build an OpenAI competitor in three months, and here’s the week-by-week progress.” Or, “I want to build a new storage engine, new database in three months.” And that’s the kind of people that we want to help, these like, super ambitious, that just hasn’t had a chance to be mentored by some of the world’s best engineers. And I just want to help them. Like, we—this is a non-scalable project. I meet with them once a week. I don’t want to have a team of, like, ten people.

Like, to me, I feel like their most valuable thing I could do is to give them my time and to help them mentor. I was like, “Hey, let’s think about this problem. Let’s decompose this. How do you think about this?” And then bring you the best engineers that I, you know, that work for—with me, and let me help you think about problems differently and give you some money.

And we just don’t care how you use the time or the money; we just want people to work on hard problems. So, it’s active. It runs once a year, and if anyone is listening to this, if you want to send it to your friends, we’d love to have that application. It’s for anyone in the world, too, as long as we can send the person a check [laugh]. You know, my head of finance is not going to walk to a Moneygram—which we have done in the past—but other than that, as long as you have a bank account that we can send the check to, you should be able to apply.

Corey: That is a compelling offer, particularly in the current macro environment that we find ourselves faced in. We’ll definitely put a link to that into the [show notes 00:32:32]. I really want to thank you for taking the time to, I guess, get me up to speed on what it is you’re doing. If people want to learn more where’s the best place for them to go?

Alex: On Twitter, my handle is @emaxerrno, which stands for the largest error in the kernel. I felt like that was apt for my handle. So, that’s one. Feel free to find me on the community Slack. There’s a Slack button on the website redpanda.com on the top right. I’m always there if you want to DM me. Feel free to stop by. And yeah, thanks for having me. This was a lot of fun.

Corey: Likewise. I look forward to the next time. Alex Gallego, CEO and founder at Redpanda. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment that I will almost certainly never read because they have not figured out how to get data from one place to another.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.