Ep. #43, You Can't Fork a Protocol with Madelyn Olson

Brian Douglas: Welcome to another installment of Open Source Ready. Today, again, we've got John co-hosting. How are you doing?

John McBride: Hey, Brian, I'm doing good. How are you?

Brian: I am exceptional, other than the fact that I've ruptured my calf muscle and I've been hobbling around the house.

John: Oh, man. You went a little too Tony Hawk on us, didn't you?

Brian: Yeah, I was skateboarding and I've also just turned 40, so a couple of different variables just didn't mix. So I am resting and recuperating, and it sounds like I might avoid surgery. It's just a longer healing process.

But we're not here to talk about my injury reserve status. We're here to talk about Valkey. So Madelyn, hello, welcome to the show. You want to introduce yourself?

Madelyn Olson: It's great to be on here. My name is Madelyn Olson. I am a maintainer of the Valkey open source project, and my day job is I'm a principal engineer at AWS.

Brian: So you actually used to be a maintainer of Redis back in the day, and then things change and now Valkey exists. I don't know how much you want to share that story, but we'd love to get your take on: why Valkey? Where did it come from?

Madelyn: At the time, I started getting involved in Redis Open Source, which is the project that came before Valkey. At the time, I was working on Amazon ElastiCache, which was a managed AWS service that supported Redis. One of the things we wanted to do was help give back more to the open source project. So I was asked to spend a bunch of my time working on Redis Open Source.

I worked a lot on stuff like adding TLS to Redis and then did a lot of operational and little bug fixes at the time. Many people know, at that time Redis was maintained by a single individual named Salvatore. He stepped down in 2020. That was also a very big event.

At that time, a new core team was created around Redis. There's five engineers from three companies. We maintained the Redis open source project from 2020 until 2024.

During that time, I was just a maintainer, mostly helping review PRs, helped with a lot of stuff. A lot of little tiny features like Sharded Pub/Sub. We rebuilt a lot of the ACL system. So that's the history of me being involved in Redis Open Source.

Then 2024 was the exciting event. That's when Redis decided that they were going to move a project to a different licensing structure. As part of that, they also dissolved the governance. So me and Alibaba were no longer part of the governance structure.

So me and Zhao went and created Valkey along with three other really active contributors from the Redis project. We had an engineer from Ericsson, we had an engineer from Tencent, an engineer from Huawei. Then we also found an engineer from Google who was very excited and wanted to be more involved in the project. So we created the Valkey project with those six people underneath the Linux Foundation.

Linux Foundation was a place to have the vendor neutral part so that we couldn't do the license change again. We kept the original BSD license that Redis Open Source had.

We create what's called the technical steering committee, which was like the core team we had before with this new governance. So this was in 2024.

The project has been going for about two and a half years now. We've launched four versions. We're going to launch a new version in the next couple of weeks. So the project is going really strong. It's exciting. It's a lot of fun. We've had a lot of good adoption over time.

John: I think what a lot of people think about Redis, or I guess Valkey, they do think about caching, caching at massive, massive scale. But something that's been really cool to see Valkey doing is more stuff, right? Sometime last year, semantic search or vector search came to Valkey. How have things evolved and changed, even outside of the Redis structure?

Madelyn: Yeah, it's interesting. Especially semantic caching is really interesting. That's built on top of a technology called vector similarity search. Semantic caching, the goal is: if your LLM produces an inference result, you want to be able to cache that result.

Instead of having to rerun the entire LLM output on a prompt, you can say, hey, is this prompt similar to another prompt? Or is this part of this prompt similar to another part of another prompt? Then you can reserve the inference result.

So semantic caching is still just the next logical evolution of caching. Valkey was obviously a point lookup cache. You have a specific key to look up to a specific value.

Semantic caching is that evolution to be like, okay, what's a point that's very close to it semantically, but maybe not exactly the same? It's close enough that you mean the same thing.

So we see a lot of evolution of that. Semantic caching has had a lot of research go into it recently because people are very interested. Tokens are getting expensive. People are looking for ways to save cost. I'll even be doing a talk about this topic at re:Invent because so many people are interested in, hey, how do you actually do this? So that's been a big feature of us.

But also, in Valkey as a whole, we're trying to both push into more AI frontiers, because obviously AI is changing a lot about how software gets written, but we still don't want to change what Valkey users think good at, because DRAM is expensive, so we don't want to try to be the hotset for everything, but just the storage for data that needs to be accessed quick and cheaply, which is caching in a bunch of different lights.

John: I'm so curious, speaking of AI, Valkey is primarily in C. What I always think about when I think of C in open source is curl, and how a lot of crazy stuff started happening with the curl maintainers. They're like, oh my gosh, we're shutting it all down, turning off contributions so that we can at least not have all this AI stuff coming our way.

How have you and other maintainers thought of this new world with a stack that maybe others would call legacy? Maybe people would say it's performant. How do you think about the stack as it relates to AI and contributions today in open source?

Madelyn: I would say up until about a year ago, it was pretty easy to accept contributions because they were mostly, I would say, AI-assisted. People were using AI to help write the code. Then starting December, January, we did get to the point where agents were independently able to just ship out PRs and changes themselves. We've seen an increase, right?

I should really update this number. But from December to June, we saw a 2x increase in PRs towards the main Valkey project. Of those 2x, we saw a 5x increase in the number of lines of code. So both of them were getting significantly more PRs, and the PRs themselves were getting much larger.

That's partially because the current generation of harnesses and frontier models are kind of verbose. They often will duplicate code, so they're running on more code. It's not as cohesive. It's a little bit chunkier.

So it took a lot more developer and maintainer time to really help clean those PRs up and be like, hey, this is duplicate, we don't need to do this. I would say the main pain point I think the maintainers have felt in Valkey is that the corresponding tools for reviews haven't had that step function yet, or at least I think we're in the process of figuring that step function out. One thing I

figured out during all this was some people call it adversarial testing, which is, hey, you have a PR and you just ask AI to try to break it as hard as you can. That's great for finding bugs. So I feel pretty good saying, hey, I don't need to go and find every little bug. I'm pretty good at AI pattern matching all the little small low-level stuff and finding the functional bugs. That leaves more time to be like, hey, big picture, what are we thinking about? Is this the right API? Is this the right data structures, the right memory layout?

So AI has helped offload some of those things, but the high-level questions are still where a lot of maintainers are spending time.

So it's in a little bit better position now. The Valkey project, throughout this year, I think we've doubled the active open PRs, but it's more or less leveled out now, which is mostly a combination of, I think, the maintainers are finally back at the equilibrium where we're able to use the tooling to offset the ability to submit more PRs.

Then the other side of that is the CVE stuff, which I know is big with curl. There's been a lot of that. There was a point in time where basically everyone suddenly had access to the same tools. So everyone was finding all these CVEs, all these bugs.

I think we're getting closer to the point where our proactive looking for bugs found at least most of them, at least the P90 of them. So the rate which we've been getting more bug reports, CVE reports, has dried up a little bit. So I'm optimistic we're in a slightly better position now, but we also still have all the tooling we had before.

I think we're in a good place now, and I'm tentatively optimistic it's going to stay better. We're about to do an RC candidate, and I feel pretty good we'll be able to find most major bugs before the GA, which before was a 50-50. It's like, well, maybe someone will find it, maybe they won't. But now I feel like a bunch of people will point their AIs at it and hopefully find more bugs.

So it's been a mixed bag. But I think on the net, it's been good. You also mentioned C, and I didn't address that. C, I don't know. It's a language.

John: I'm just so curious. I used to write a lot of C way back in the day. I kind of miss it, actually.

Madelyn: I really like C. For a minute, the logical other choice is Rust. I'm a big Rust fan girl.

I really like Rust. It gives you a lot of compile time checks. The borrow checker is really helpful. The lifetimes are really helpful. The typing system is great.

It's good. And the errors it generates are so useful. The LLMs are great at being like, ah, this didn't compile because of XYZ, I can fix this. So it would be nice if more of our codes were in Rust.

There's a recent CVE that I found in our code base that was really old. It's actually in the TLS code I mentioned before. And so it's been basically all versions. And it was found because of something that was caught by the Rust borrow checker. Rust would not let you do that. And so it would have been nice if we'd use Rust, but I don't know.

I think if we were to write Valkey from scratch, we'd write it in Rust. But I do wonder if it's worth the whole churn on the project to move from C to Rust.

I think at some point it'll happen. But I don't think that time is now yet.

John: And there's just so much prior art, too, that history, which I'm guessing is mostly preserved from the Redis fork.

Madelyn: Yeah, it's great. Every once in a while, we'll be like, why is it written this way? And we'll go back and look at the PR and realized they didn't even think about it. I'm like, well, this was a happy accident.

Brian: And this is something John and I have been chatting, because we run a project that captures sessions called Tapes. And the thing about this is when you have sessions and you have this history, you have to get history. You'd always go lean back on history of, oh, this is how we did the thing.

And I know recently, what was it? SQLite got a rewrite. Was it Cursor that basically one-shotted SQLite to Rust?

John: Oh, did they?

Brian: I don't think anybody's actually using it. They tweeted it.

Madelyn: The only one I've heard about is Bun, but I think SQLite was talking about it.

Brian: Sorry, I don't think it's anything anybody's using. It was just a tweet, and no one had any proof. But it was like, hey, we're using all this compute to basically rewrite SQLite in Rust. And it was right after the Bun thing.

But the thing you miss on the rewrite of SQLite to Rust is that history. It is like, why did we make these decisions? Or why did we get to this point? You could train so much, but there's a lot of missing information on training that.

So I guess the question I would have for you is, do you feel like the barrier of entry to make contributions or maintain a product like Valkey is harder or easier now that AI exists?

Madelyn: I think in almost all cases, it's easier, because you're either someone who has a feature request. If you're an end user and you don't know C, it's much easier to be like, I want X, Y, Z, and just ask the LLM to go do it. And I like that it lowers the barrier for them to go and open the PR, right? Because if they want a new command that does XYZ, it's much easier for them to just go do that and then shape it the way they want.

And then we at least, as maintainers, understand what they're looking for, the behavior they're looking for. And code is a great way to concisely understand what they want.

The people who are using AI the best these days that I see are strong senior engineers who know the fundamentals of coding, and they can write very crisp, concise prompts of, I want you to build X, I want you to do Y, I want you to think about this, I want you to add these constraints while you're building it.

And before, I would say you stick like a month to ramp someone into the Valkey project so that they understood and could contribute pretty independently. And we've seen people in like a week ramp up on the code base and be able to contribute material features. And I think that's really good. So I think it's made it easier.

There's definitely some classes of stuff. There's stuff that we don't care about anymore. I'm trying to think of the best example. I think there's definitely small typos and stuff that people still open PRs for, but those are so low-hanging fruit that we just don't care anymore. And we'll usually just close them.

John: It's like the Hacktoberfest PRs.

Brian: Typo Hunter.

Madelyn: I think it's easier, and I think that's good. It makes open source more approachable.

Brian: That's great to hear. Because we've definitely had a number of guests who are like, it's the opposite of it. But it's also, we had Mitchell Hashimoto on an earlier episode. And obviously with the Ghostty experience, it's different. It's a smaller team. This is before he went and created the new company.

So I could feel for everyone between January and June, we're just like, what is going on? How can we navigate this new world? And I just recently had a GrokBot. I decided to test it this morning.

And I basically built a little app like Tinder where I can swipe left and right and then up for skipping for my inbox. Because I want to respond to emails, but I don't want to respond to some emails yet. So I just one-shotted a little mobile app for this.

And immediately it opened a Cursor Origin account and then created a repo there. And I'm like, oh, this is interesting. What I'm getting at is this is a throwaway app. I don't care if it's on GitHub. I don't care if it's on Cursor Origin. I just want the output of it to see if this solves the problem for me.

And I think we're now in a world where people can one-shot and build a bunch of throwaway noise in code. But then all these other things that we are dependent on, and if we're going to build our system on top of the Valkey system, there is an expectation of, yeah, we should probably figure out what's the minimum viable. And I guess this is your steering committee, and you have maintainers as well.

Madelyn: I really get what you said. In June, I was feeling really overwhelmed. I was just like, what do we do about this? Because the AI slop has a couple of dimensions.

One is people would open PRs and the summary would just be slop. What would have been a two-sentence description of the PR was, this is what I do. This is what I considered. This is what I was told to explicitly make sure I tell you because it's part of my system prompts.

And they're so unreadable. And I think both people are not doing that as much. I think people at least know that you're not supposed to just slop stuff.

And then also, there are times if I look at a big AI slop summary, I'll just ask my AI to summarize the AI slop summary. And then I read the summary. And then I understand what's going on, and I didn't have to read this, which is not ideal. I would like to get to the point.

We even have a bot that we're working on, which if it detects that a summary of a PR looks AI slop, it will rewrite it at the bottom. So if I see it, I'll look down, be like, is there a summary on here? Which is nice. I don't think it's an ideal world. I feel like I might be overly painting a rosy picture, and there's a lot of issues and there's still things we're working through, but I tend to be an optimist that try to be like, how do we take this tool that was given to us, which is chaotic in many ways, and try to make the best of it.

John: A big question I have for you, because you're right in the middle of it with Linux Foundation and the SIGs and committees and all this stuff, is this take from David Crawshaw, who was at Tailscale, now exe.dev, and has been doing a lot of interesting things with agents and what he calls personal software.

And he had this blog post about dev tools must be open source and how really everything should just be open source so that at least you can go in, get your agent to fork it, change the few lines it needs to make, I don't know, make the button blue or something, and then it'll just do it, and then it's there for you. Instead of having a thousand config flags on the thing to select the hex code for the blue button or whatever.

It triggered me because I was like, oh man, but what about the people? What about all the structures and the ways you build a project and the culture around a project if a thing is just meant to be forked away and never looked at again?

Where do you see the value in the things that you've built around Valkey and the committees and the relationships and the people? Are we headed towards a world where ultimately that'll dissolve and it's all just personal software that gets forked and everybody has their special flavor Valkey somewhere?

Madelyn: I'm aware of this argument. It's not terribly new. And I think it's probably some amount of our future. Once we get to the point where everything has been, I don't know, solved, how much more software needs to be written or just modified.

It's interesting. One of the things that Valkey and Redis before were BSD. And one of the reasons that's such a good license for a lot of folks is you could just make changes to it and you could do what you need to do with it.

On Amazon ElastiCache, we had a fork of Redis open source for a long time. We had all these little random tweaks. We had random features. And we didn't want to wait for open source. We also didn't want to maintain it independent of open source.

One of the things that's missing from the argument is, every time open source changes, when you rebase it to get new features, you have to merge those rebases. So there's still a cost, and I might do it wrong and might introduce bugs. It's still better to upstream most code.

Even in Valkey today, there are some contributors who have custom internal forks of the code with very specific proprietary things. And they're fine maintaining that, but they still come and be involved in Valkey because they want the ecosystem, they want the standards. I think the Valkey and Redis API is the standard that everyone will continue to build around.

I don't think you're going to personal software your own protocol, right? Because then nothing works with it, unless you're going to build entirely your own stack.

And it's like, do you want to spend tokens to go build that whole stack? Maybe there's a future where tokens are so cheap that we do that, but at least for the near term, tokens are too expensive to just build everything. So it still makes sense to pull most things off the shelf.

The thing is, I agree with the idea, oh, it's easy to go make your own little tweaks to the thing. So I think it's a mix of both. I don't think everything will be personalized, but I think the great thing about open source is you can personalize, and people have been personalizing.

The ElastiCache fork I mentioned was 2012, 2013. It was when we first forked it. So it's not a new thing. And it's the great part about open source.

Brian: I was going to say, the dance is always good as long as the music's still playing. And I would say with open source...

Madelyn: Sure. The dance is still good. The open source dance is still good.

Brian: Yeah, the music's still playing. I think we have some questions about its future. But at the moment, at least we have turned a corner around agents. And I think we're mostly accepting or we're rejecting the existing agents within open source.

So there's probably a minority of projects that are like, okay, we're done. Turn off PRs. I think now you can get added extra features for management of interactors and basically curbing a lot of that noise.

It's a long time coming. And I'm a former GitHub employee. So I can empathize with the team.

And I've been on the other end with security incidents and DDoS attacks and stuff like that, where up until this year, it wasn't even an event. It was just like, oh, hey, we blocked 17 of these things happening. Now it's like, okay, GitHub's down. I guess I'll be doing something else. I'll be chatting with ChatGPT for the rest of the day about something.

It's an interesting world. I'm actually curious, what do you think... This is more a pie in the sky, but we're at a point where everyone has an opportunity to go try and personalize software. Do we have a world where we have a lot more microservices, open source things that everyone's personalized for themselves, and we have a bloated GitHub, Cursor, wherever you host your code?

Or maybe we have your own GitHub and your own hardware internally at your house? Or do we have a bunch of people who just check out? Because there is the other thing where people want to quit tech and create bake shops or go farming. Are we now at that point where we're going to go farm and agents will work during the day while we're out in the fields?

Madelyn: That's a great point.

John: I'd rather be playing guitar, Brian. Come on.

Brian: Okay, replace farming with guitar or whatever. But I don't know. I bring this up because I've been reading a lot more books lately. And the reason for it is I will have some long-running sessions going.

I don't have a book on the desk now, but I will run it. I'll just let my brain work for a little bit. I feel like I got to fight back for that. But I don't know. This is probably a more esoteric question, but I don't know if we were ready for this part of the conversation yet.

Madelyn: No, I'm glad you said a little bit more, because I was still trying to find words for my response.

Madelyn: The thing that you said that resonated the most with me is that my work has definitely changed, where sometimes I'll get in the morning and spend an hour really finely crafting a bunch of prompts and AI follow-ups and constraints and be like, go do this. And I'll just be so tired from that. It'll be so hard to do it that I will just go and chat with people in the office for an hour.

Because it's so much. It's such deep thinking. You have to think about so much stuff.

It's a lot. And everyone keeps saying, how do we scale more, do more with less. And I just don't know how to do more, Because I feel like I am at my limits.

And I know there's a bunch of frontier research being done about how to offload more of this reasoning work. How do I not need to think so hard? Just go ask the AI, hey, go build this feature.

Because the real thing that I still haven't done: if I ask it to write code, how do I trust that it built the right thing? And there's this gap that I don't know how to get over yet.

And so once we're over that gap, I don't know what I'm going to spend most of my day doing. That's what I spend a lot of time doing today. And to your point, would I go learn guitar? Guitar sounds fun. So I don't know. I don't know when that's going to happen.

Brian: You had mentioned there's a release coming up for Valkey. What can we expect coming down the roadmap?

Madelyn: Valkey 9.2 is going to come out. Or release, it's actually on Tuesday, hopefully. We'll probably be a day late, because we're always a day late, but it's a release, it's not that boring to hit the day.

The big things in this release, there's just three features. The first is, historically, the replication implementation we inherited from Redis was based off a fork. So you did a Linux copy-on-write fork, and inside the fork process, you dump out a full snapshot of the memory. So any mutations that came in during that snapshot would copy the memory pages, which QA to what we call copy-on-write memory. So it was a very expensive memory operation, especially for an in-memory database, like an in-memory cache. You don't really want to be doing that.

So now we have a forkless-based implementation of a snapshot inside Valkey. The initial version is just for snapshots. So if you're doing an AOF, like a disk-based snapshot of the data. But the next logical step is to build this into replication.

So we'll have a much more memory-efficient snapshotting and replication system. That's the end goal, and we built part of that today. So you can take snapshots efficiently.

The other big thing that we've spent time on in Valkey has been memory efficiency. A lot of the data structures we inherited were very much out of 1990s textbooks. And so we've been spending a lot of time trying to optimize them.

Some people know there's a data structure in Redis called the sorted sets. And it was based on a data structure called a skip list, which is a fine data structure, but it's not very memory efficient. And so we moved to a B+ tree, which is more of the modern standard.

So it's actually called a feature B+ tree. It's a very specific type that's more memory efficient. It's more dense, so there's fewer memory lookups to get the data you want.

So those are two of the biggest features we built. There's a lot of other stuff, like we had replication compression. There's some other access control improvements. So there's a lot of other things that are coming out in the release, but those are the big ones.

John: Wow. Sounds amazing.

Brian: I've not paid attention to Valkey since the first year, but I'm actually excited to dig in and check it out.

Madelyn: Thanks.

Brian: Excellent. So Madelyn, I'd mentioned earlier, we have Reads. So the question that I have for you is, are you ready to read?

Madelyn: I am ready to read.

Brian: Excellent. I will start with my first read. My first read is, Apple has invented the foldable phone today, which is mostly a joke. Usually Apple is super late to the party, but today they announced a foldable phone.

It's a quick read because I was literally just reading up on this today. I think this has been rumored for a long time. And congrats to my friends who work at Apple who never tell me what to get shipped, because I imagine they were super excited to finally show what they've been working on. But I guess question to both of you: foldable phones, is it hot or is it not? I'm indifferent, to be quite honest.

John: I think it's a little dorky, but when you need to open it up and then start talking to Claude in a terminal, which I saw one of our coworkers, Jason, doing, where I was like, oh, man. And then he shows me, like, yeah, man, I got Claude up in here, full keyboard with Claude in a terminal. I was like, blows my mind. It was amazing.

So definitely getting it. Definitely going to open the terminal up in it. It's a little dorky though.

Madelyn: I love this. I am so excited. I am one of those people. I have two primary devices I take when I'm out and about. I have an iPad mini, which I use for reading out, and I have an iPhone.

And I feel like I could replace both of those. My only concern is I think this is going to be $8,000. I'm like, it's still cheaper just to have the two devices separately.

Madelyn: It'll probably be more affordable than that. But I am excited. Also, the hinges have never really worked well. I'm curious if they got the hinges down.

Brian: Yeah, I imagine they did, because I know of other projects that have never made the light of day because it wasn't perfect. It made the ghost of Steve Jobs live on and have the pedantic of making sure everything is super smooth and designed very well.

I don't know. I haven't had my hands on it. I literally was on a call while it was being announced. And then in between that call and this chat, I was reading about the foldable phone. So I don't know if I have a use case for it.

I also do have a 10-inch iPad that I do pull out. I like that it has a keyboard. I've got the keyboard case, so it's my go-to if I do want to go straight chat, and I'll pull up a Termius session and I can have an experience that doesn't need my full laptop open for.

But I don't know. I do a lot of walking and talking to my agent as well. Again, I'm indifferent, but I'm also price sensitive. If it's $8,000, I'll just buy a GPU instead.

Madelyn: I think it's interesting you guys do so much interactive stuff on Claude. I'm very much a big person of, I don't want to be talking to AIs.

I don't like interactively talking with AIs. I am the same version where I will spend an hour giving it a very precise thing, and then I don't want to see it until I'm ready to look at its response, and I'll be like, the next day.

Brian: You're like director level AI. I'm still grunt. I'll be pair programming with it and looking at it. I think there's different levels.

I don't know if this paper was ever written, but one of my former co-workers at my last job, he was talking through the idea of level one, two, three, and four of self-driving cars. When Waymo first started, operators had to drive the car and then map out the route.

And then level two, operators can let the car drive. Level three, operator sits in the passenger seat. And level four, it's just full-on, operators not in the car, it's just passengers. So we're here with Waymo, at least here in the city. I don't know, Waymo in Seattle now?

Madelyn: They're driving around, but Waymo has not launched. But I've been in Waymo, so I've been to the Bay Area.

Brian: So you get the idea. And I guess if you're going to be at re:Invent, I think they have them in Vegas now. But what I'm getting at is, I think that your comfortability of whenever you're first in self-driving versus you're comfortable just letting it drive because you have confidence it's going to do the thing that you can at least review after. That's an interesting whole paper or whole talk that we can have hopefully in a future conversation. So I think I'm going to get Ty to come on the podcast and talk about some of this stuff he's been writing.

John: It'd be very cool. Well, I had a couple reads. First one is very exciting for me: rootless Kubernetes is now in beta, I think in 1.37 Kubernetes. This is personally exciting to me because I remember, gosh, back when VMware was still a company and I was working there, people were asking for on the Tanzu suite of tools and things.

The TLDR is that if you need root on one of the nodes, on the kubelet, and something escapes, then you have root on the node. From a security perspective, this is pretty exciting that Kubernetes is getting stronger and more powerful, which is great.

Madelyn: I know, that is really cool. I don't know much to say about this. There's a version of Valkey replication we wanted to use that you needed to set some root permissions on the change that made it inherently insecure. So I'm glad they're continuing to work on this stuff.

There's a system called CRIU. I don't remember exactly what it stands for, but it allows you to basically dump out the entire contents of the memory pages. And we needed to do what's inside Kubernetes. I mentioned before how fork works. You could do the fork basically on another node. And every time a key was modified, you copy the page to the other node instead of doing it on the node itself.

And we were running into problems with Kubernetes. Everyone runs Valkey on Kubernetes. So the fact that they're continuing to progress in this, I'll go follow up on this and see if it helps solve some of the problems.

John: I think it's exciting. Especially with the boon of AI, I'm sure there's people just being like, hey, we really want to run sandboxes on Kubernetes, like pods on Kubernetes, but there's just some of these deeper primitives that I think people have been shouting about for quite a long, long time.

I remember talking to some Podman people at Red Hat way back in the day being like, we should really do rootless containers, because you don't want the container break out and then it's a bad time all around. Exciting stuff is happening all around the industry, communities included.

Speaking of exciting things, Envoy AI Gateway renamed to Agent Gateway and has been donated to the, what is the name of this?

Madelyn: The Agentic AI Foundation, AAIF.

John: That one, yes. Really, really cool project. Congrats to those maintainers. I think it's one of the better AI gateways out there, kind of had one of the last mover advantages of also being on Envoy, which is just incredible. Definitely go check it out, folks.

Madelyn: I'm excited about that. Especially on the MCP server side, where people would just launch billions of MCP servers and be like, how do you connect to stuff? Again, like the ElastiCache world, people would create MCP servers per ElastiCache cluster. I'm like, this is such a pain. We need someone to win this space, is all I'm saying.

It's just one gateway you can connect to and it will route you to where you need to go. So I think everyone consolidating at one is a great outcome.

But donation to the foundation is really important.

John: I don't know about consolidating, because there's still so many of these projects and companies and people out there doing that, but it's neither here nor there because Envoy is great.

My last read was actually a book, Dune Messiah, which I finished a week or two ago. I can't remember if I talked to you about this, Brian, or not, but I randomly picked it up because I'm excited about the movie coming out in December. It was so good. I think it was better than the original Dune.

It felt very topical for all these AI researchers being like, oh no, AI is going to kill us. Anyways, let me keep working on this. Because the TLDR of the book is that Frank Herbert really wanted to nail home how problematic Paul as an antihero was and just the terrible things that ensued because of him. Great book. Recommended.

Brian: Man, amazing. I actually want to put that on the list. I've read a couple books that you read recently. Or sorry, you recommended books maybe a year or two ago.

John: Sure. Which one?

Brian: Hyperion.

Brian: I really enjoyed that one. And then I've actually just started the Silo series as well, because that show just completed. It's second season, I think.

Brian: Or third season. Not sure which one. But there's three books. So I'm really hooked on trying to figure out what's going on here and let me get the background of the story.

John: I need to pick that series back up. I never finished it, but it's a good sci-fi mystery. Madelyn, have you read any of these books, or I guess read any good sci-fi recently?

Madelyn: I have. Good sci-fi, Ancillary Justice was the book I just finished. I thought it was delightful. The main character is basically the spaceship. Cool artificial intelligence stuff.

Dune Messiah, also fantastic book. I was gonna jump in with the thing you said, which was that it was Frank Herbert being like, no guys, Paul Atreides is not a good person. Do not be Paul Atreides. We don't like him. It's such a good book. The other, Hyperion, I have not read, but it's been on my list. I'm a big science fiction person, so there's just too many good books.

Brian: Well, if you're letting your agents cook, you got some time.

Madelyn: Right?

Brian: Amazing. Well, Madelyn, thanks so much for coming on, talking about Valkey, giving us the origin, giving us the state of the new release candidate coming out pretty soon. So by the time this comes out, folks, get your hands dirty, try it out, embed it into your systems, and stay ready.