Screaming in the Cloud - How Redpanda Extracts Business Value from Data Events with Alex Gallego

Episode Date: August 31, 2023

Alex Gallego, CEO & Founder of Redpanda, joins Corey on Screaming in the Cloud to discuss his experience founding and scaling a successful data streaming company over the past 4 years. Alex explains how it’s been a fun and humbling journey to go from being an engineer to being a founder, and how he’s built a team he trusts to hand the production off to. Corey and Alex discuss the benefits and various applications of Redpanda’s data streaming services, and Alex reveals why it was so important to him to focus on doing one thing really well when it comes to his product strategy. Alex also shares details on the Hack the Planet scholarship program he founded for individuals in underrepresented communities. About AlexAlex Gallego is the founder and CEO of Redpanda, the streaming data platform for developers. Alex has spent his career immersed in deeply technical environments, and is passionate about finding and building solutions to the challenges of modern data streaming. Prior to Redpanda, Alex was a principal engineer at Akamai, as well as co-founder and CTO of Concord.io, a high-performance stream-processing engine acquired by Akamai in 2016. He has also engineered software at Factset Research Systems, Forex Capital Markets and Yieldmo; and holds a bachelor’s degree in computer science and cryptography from NYU. Links Referenced:Redpanda: https://redpanda.com/Twitter: https://twitter.com/emaxerrnoRedpanda community Slack: https://redpandacommunity.slack.com/join/shared_invite/zt-1xq6m0ucj-nI41I7dXWB13aQ2iKBDvDwHack The Planet Scholarship: https://redpanda.com/scholarship

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. Tired of slow performance and bottlenecks on MySQL or PostgreSQL when using Amazon RDS or Aurora? How'd you like to reduce query response times by 90%?

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 Ottertoon's artificial intelligence to automatically optimize and keep their databases healthy. Go to ottertoon.com to learn more and start a free trial. That's O-T-T-E-R-T-U-N-E dot com. Welcome to Screaming in the Cloud. I'm Corey Quinn, and this promoted guest episode is brought to us by our friends at Red Panda, 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 Red Panda. Alex, thanks for joining me. Corey, thanks for having me. 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? 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 Red Panda 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, 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. In large, it's data contextualized with the timestamp and largely that's sort of the base of event streaming. 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 they're, 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 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?

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 transfer between the hyper clouds and your accounts, send in a gigabyte a second of data between, let's say, your data center and a vendor, it's just so expensive that at some point, from just the 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 BYC, to be honest, which is why we called this offering, it was about sidestepping the cost and of being stuck in the hyper 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, 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 is probably like, you know, a hundred feet away from my customer's computer. Like, why is that so complicated? So, you know, my view is that the future of data-intensive products will be in this form of where like

data planes are actually owned by companies. And then you offer that as a software as a service. 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's regions. So 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, all of the data transfer pricing that at least AWS tends to present. And it shapes the architectural decisions you make as a result. You know, as a user, it just didn't make sense when we launched this product, there are a

number of people that said, why wouldn't you charge for effectively renting AWS and giving a markup to your customers? 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 MSKs is 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 hyper 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 others, latency and sovereignty. This is the way that effectively all of AWS's 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 of actual anti-competitive behavior in the market. But it's also complex enough to explain to regulators that it doesn't make for exciting exposés and the basis for lawsuits. Yet. Hope springs eternal. You know, okay, so here is how, if someone is listening to this podcast, it's like, okay, well, what can I do i do for us s3 is the answer is there is basically you need to be able to lean into s3 as a way of replication across ac you need to be able to lean into s3 to read data and so actually when i wrote originally red panda you know it's like the c++ thing using a threepen chord 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 AC network transfer, which is basically free, to be able to then bring a separate cluster on a different AC

and then read from that 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 there are deep implications of what it translates to at the technical level, like at the code level. 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 at least one customer of mine. It's fine 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 cosplay, 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? From our customer base, I would say 40% of our customer base is about Red Panda enabling them to do things that they simply couldn't do before. An example is we have a Fortune 100 company that

they basically run their their hedge trading strategy on top of red panda and the reason for that is because we give them a five millisecond average latency with predictable flat latencies right and so for them the predictability of red panda you know and sort of like the architecture that came about from trying to reinvent a new storage engine allows them to throw away a bunch of in-house, you know, custom-built pop-up messaging that, you know, basically give them the same or worse latency. And so for them, there's that.

For others, I think in the IoT space, if you have flying vehicles around the world, we have some logos that, you know, I just can't mention them, but they have these 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 want to measure that. And so the profile of the footprint, the mechanical footprint of being able to run on a single P-thread with a few megs of

memory allows these new deployment models that simply it's not possible with the alternatives where let's say you have to have a zookeeper and a schema registry and an HTTP proxy and a broker and all of these things. That simply just cannot run on a single P-thread 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 is just money was really cheap last year or the year before. And I think now it's less cheap. Yeah, I couldn't have noticed 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? Exactly. And now people are like, you know, the CIO is in particular. And so that's really 60% of our business has boomed since. 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, but completed a $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 competitors' earnings calls, where they were asked by an analyst about an unnamed company that had raised $100 million Series C, and the CEO said, oh, you're probably talking about Red Panda.

And 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 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 that in a place where you normally don't see competitors validate that you're doing something interesting by name checking you. What was fundamentally interesting for me about that is that I feel that as an investor, if you're putting, you know, two, three, four, $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 this Series C startup company that now has a bunch of this Fortune 2000 logos. And when we, you know, when we talk to them like their customer release is phenomenal like why is that the case and then you know our competitor was forced to name you know a single win that's as far as i remember 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 percent 97 percent 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. On some level, it's a little bit of a dog and pony show. I think that as companies hit 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, the 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 Red Panda has increased after initial proofs of concept and putting things onto 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. You know, Jump Training just recently posted that there's a news case in the news stack where they put for their most mission critical, so for those that are listening, Jump Training is this financial company.

And they're super technical company one of like the hardest things they'll probably put your gear or your product through some of the most rigorous testing you know so when when you start doing some of these logos it gives confidence and actually the majority of our the developers that we get to partner with it was really a friend telling a friend telling a friend for the longest time my market 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 last one is when you have workloads at like 14 and a half gigabytes

per second where the alternative of using something like kinesis in in the case of lacework which you know they wrote a new stock about, would be so exorbitantly expensive. And so in a way, I think that just trying to make the developers 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. And we're just trying to figure out the whack-a-mole of trying to debug alternative systems. 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 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? It's true. The people that have built a career, especially at large banks, were a pretty good fit for. Here, they actually get a team. They got a promotion cycle because they've read this technology and the technology sort of helped them make money. I personally tend to love to talk to these people. And I was like, hey, tell me like technically, let's talk about like deeply technical. Let me help you. And that obviously doesn't scale

because I can't have the same conversation with 10 people. So we do tend to see some of that. Actually, from our customer standpoint, I would say that a large part of our customer base, you know, if I'm trying to put numbers, maybe 65% are probably reap 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 rain. 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. And so, you know, then really my job is to help them look like a hero. I was like, hey, look, try it, test it, benchmark it with your own workload.

And if it saves you money, then use it. That's been, you know, sort of super helpful, kind of from the macroeconomic environment. And then the last one is sometimes, you know, you do have to go with the 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 have to go with the green field 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 and your 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 keep this team. 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 exist. And I would say 65% is probably ripouts. one question i love to i wouldn't call it ambush but definitely come up with that 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 you have an example of a data streaming workload for which red panda would not be a great fit yeah database style queries are not a fit and so i think that there was a streaming engine before that was trying to build a database on top of that. And like, and probably it does work in some low volume of traffic, like say five, 10 megabytes per second. But when you get to actual large scale,

it just, it doesn't work. And it doesn't work because what Red Panda 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 cache and level to be able to give this database semantics. And so, 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 database, like bring in

Snowflake or Athena or Trino or Spark or ClickHouse or DuckTV or whatever, the other tens of great databases that are better than we are doing MPP, right, like a massively parallelizable database, do that. And then the job for us, for Apache, 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 CRC fund, and it's like, I'm going to put the data in an iceberg format so you can go and query with the other 10 databases. And they're a better job than we are at that, than we are. It's frankly refreshing to see a vendor that knows, 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's 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, but it also 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? Yeah, 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 pressure. It's like, hey, you built this great engine.

Why don't you add like the latest, you know sub-dissurance systems was like a vector database. I was like, this doesn't make any sense. For me, I want to do one thing really well. And I generally call it internally the ring zero. If you think of the internet 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 being average at a bunch of other 100 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 this. 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. I think that that is something that's underappreciated. I feel like I should get over to 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 Red Panda yourself in, was it C or C++? C++. 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 work around them to keep them from 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? 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 piece of humans. And so group of humans i stopped coding about two 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 two years definitely i was personally putting like tons and tons of hours working on the code it was it was a ton of fun to me one of the most rewarding technical projects i've ever

had a chance to i still read pull requests though just so that when i have a conversation with the 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 DevPro team removed my write access to the GitHub repo. We got sucked to compliance. They're like, you can't have access to be in 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, my self-identity is that of a builder. And I think as long as I personally feel like I'm building today's, it's not code, but,

you know, it's the company and the same sort of culture. Then I feel okay. But yeah, I no longer write code. And the last story on that is this, an engineer of ours, his name is Stefan. 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 the semaphore.

I'm sorry for this bug I caused. But yeah, at least I still remember some context for them. 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. Totally. It's, you know, it's the feeling of being before I think I became a CEO, I was like highly calmed engineer and, you know, competent

to the extent that 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 discovery but I have to get it done because no one else wants to do whatever let's say like you know rev ups or marketing or whatever and then you find somebody who's great and you're like oh my god I, I was so, so poor tactically at doing this thing. And so it's definitely humbling every day. And it's almost this like, gosh, you're just, this CEO is 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 like 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. 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 would 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 that place doesn't exist. Every time I talked to someone about how they built the thing that they built, and I asked 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 going

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? Gosh, so many things. But if I were to give Hollywood highlights on these things, something that Redis does well is exposing this high-level data types of 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 it. The whole thread per quarter, the fundamentals of the engine, I would 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 widely different use cases that 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 up front i would have pushed a little harder on i think web assembly than we did originally man i could just go on for like added detail i would definitely have changed things like i would have pressed on the first version of the cloud that we talked about early on that as the first deployment mode model. If we go back through the stack of all of the products,

there's probably like 11 products that are surfaced to the customers, two like business lines. I would change fundamental things about just, you know, everything else. I think that's maybe the curse of the expert. Like, you know, you could always find improvements. 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, 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 with an eye toward making it look as enterprise-y as possible. 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 idea, especially when we go and we talk to banks, is true.

They're like, hey, I have this contract with one of the hyperclouds. You know, it's usually with two of them, and then you're like is my workload i want to spend 70 million dollars or 100 million dollars who could give me the biggest discount and then you kind of shop it around but what we are seeing is that the effectively the data transfer costs are so expensive and and running this for some of this large volume traffic is still so so expensive that there is an inverse strength to host from some category of the workload where you don't have dynamism. Actually hosting in your data center is like a huge boom in terms of cost efficiencies for the companies, especially where we are. And especially in finance, since 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 market's 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 on market close. Like I could provision my hardware to be 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. And for us, because we offered the self-hosted Red Panda, which can adapt to super low latencies with kernel parameter tuning and the cloud due to the tiered storage.

We talked about S3 being that. And so it's been really fun to participate in deployments where we have both and they couldn't look more different. I mean, it almost looks like two companies. 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? 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 escape that is that, you know, people were just that look like me are probably given some bullshit QA jobs to test some 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 them 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 their couch if they want to. No one has to disdain. 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. And often their minds, which is great, and they're like, I want to build an open AI 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. There's like super ambitious that just hasn't had a chance to be mentored, but some of the world's best engineers. And I just want to help. There's like super ambitious that just hasn't had a chance to be mentored, but 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 10 people. Like to me, I feel like the 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 so,

and then bring you the best engineers that work with me. And it's like, 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 our 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, my head of finance is not going to walk to a money gram, 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. 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. 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?

On Twitter, my handle is emaxerno, which stands for the largest error in the kernel. I feel 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. Likewise. I look forward to the next time. Alex Gallego, CEO and founder at Red Panda. I'm cloud economist, Corey Quinn,

and this is Screaming in the Cloud. If you've enjoyed this podcast, Thank you. because they have not figured out how to get data from one place to another. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.