Ep. #59, Containers Should Actually Contain with Emily Long and Alex Zenla

Rachel Chalmers: Today is pretty much my birthday because I have two of the founders of one of my favorite startups ever in my career in the studio. Emily Long is the co-founder and CEO of Edera, the pioneer of strong workload isolation technology for cloud and AI infrastructure. She places the highest value on people and building diverse teams and brings to the CEO role a background that's unusual in enterprise security, operations, culture, and human resources rather than engineering.

Prior to Edera, Emily was COO at Chainguard, where she built and scaled core business functions that helped take the company to its Series C and unicorn status. Before that, she served as Chief Operating and People Officer at Anchore and spent 12 years at KPMG across HR, campus recruiting, and assurance services.

Alex Zenla is the co-founder and CTO of Edera and one of the most unconventional engineers in enterprise infrastructure, now 26. She began exploring hypervisors and hardware at age 7, contributed to Chromium and Chrome OS at 11, earning an invitation to Google I/O in 2012, contributed to the Dart programming language at 13, was hired at 14 to build an IoT platform at DG Logic that would eventually put her in front of Fortune 500 companies and Google.

The technical insight behind Edera came from Alex's work rewriting the Xen hypervisor in Rust for edge and IoT applications, when she recognized the same approach could solve a decade-old unsolved problem in container security. She co-founded Edera in 2024 alongside Emily and Ariadne Conill, making it one of the rare all-female co-founding teams in deep infrastructure.

And of course, the Generationship Fund, which will be publicly announced by the time you listen to this podcast, specializes in technical women building deep infrastructure. Edera was one of our earliest investments, and we are absolutely delighted to be on the cap table. So Emily and Alex, thank you so much for coming on the podcast.

Emily Long: Thanks for having us.

Alex Zenla: Yeah, thank you. I appreciate it.

Rachel: Alex, you were rewriting the Xen hypervisor in Rust for IoT when you realized you'd stumbled onto something much bigger. Walk us through that moment. What does it feel like to recognize you've accidentally found a different problem to solve?

Alex: This is such an interesting question. I feel like some important context to know is that although I started in IoT, my interest had always been in developer tools as a developer, right?

I think that's one of the funny things about how we build software in the modern day. More people are thinking about tools more often than ever. And it was very natural for me to have the not-invented-here syndrome in the IoT industry, which is all about, I'm going to build my own thing because then at least I know it end to end. And to be honest, some of that might have contributed to this decision.

But I think there's a few interesting things that happen when you're developing something so complex like that. My goal ultimately when I was building what eventually became Edera was actually to learn and also to solve a problem.

I believe very deeply that the best way to actually solve problems is to be learning at the same time, because if you're not learning at the same time, you're doing the same tired old thing that you've always done.

And although I had known a decent amount about hypervisors before this, I was not an expert in them, far from it. I had maybe done a little bit of kernel development before. And so I think, honestly, what happened and how I adapted this technology when I realized that, oh, it can be more than what I'm thinking of, is realizing that I did know what I didn't know.

And as you start to build things, I think it's very important to not have tunnel vision and to think bigger. And ultimately, what I ended up on was realizing that, hey, this is a lot bigger than what I'm thinking of, or this could be useful to other people. Of course, it's always in the back of your mind, oh, feature creep, I could build this thing and then make it more useful to other people.

But I would say it was a thought in the back of my mind until Ariadne, who was an additional co-founder of Edera — I was sitting at a WeWork with her just across the way from my apartment. We were talking about what I was doing because, to be honest, I was building this thing in my free time, not for work. And she's like, I think that this is bigger than even you think it is because this is solving a problem in the container space, which, although I was a consumer of the container space, I would not call myself a cloud-native person prior to Edera. I was a consumer of said results, but not really part of that group.

And it was a very interesting moment for me because I had always had this inkling in my mind that really IoT, or the part that I loved about IoT, was actually the developer experience. Because in IoT, your users are technically other engineers, but not software engineers. Usually, it's actually electrical or mechanical engineers.

And in this kind of a messed up way, that developer tools experience was what I was doing and what I was actually enjoying out of that. And so being able to actually do it to platform engineering or other types of engineering was really interesting for me. And it was very much a light bulb moment.

And I ultimately poured basically all of my time and resources into it. And that's how Edera came to be. And I have Emily and Ariadne to thank very deeply for that.

Rachel: Why Xen, though? Given your background, KVM or even unikernels might have been a more logical approach. And I say this having grown up in Xen world and then Docker came along and was the new hotness and broke security for a generation. How did you find the ancient texts of Xen?

Alex: It's a great question. It's funny because I did not know much about Xen prior to Edera. I had known it existed, but I had never touched it once before.

What I recognized was that KVM was a new thing. New in the sense of, it's only been around for a certain amount of time. And I knew that virtualization had been done before. And I also vaguely knew that KVM was not a bare metal hypervisor in the true sense.

So I started researching it. And Xen had become the child we don't talk about.

Rachel: We don't talk about Bruno. He lives in the walls.

Alex: Yeah, exactly. So it became that way, and I'm always annoyed by that. I think that the vast majority of good computing solutions come from places that people least expect.

I'm very interested in Apple and macOS and other Apple platforms, and they also do things very differently than everyone else and to great results, I would say. And so I think there was an element of curiosity. And to be honest, the way that I ended up using Xen was primarily because I stumbled upon it on a Wikipedia article when I was down a rabbit hole.

Rachel: Oh my God, that's amazing.

Alex: Yes. And when you read the history from that perspective, it helps you understand what the value of something is better, because when people are using tools from a day-to-day, the user experience of Xen was kind of mediocre in the modern age. And that's why people were drawn away from it.

But what I realized is the user experience is the least interesting part from a technical perspective of Xen. The benefits that lay behind that are so great.

And that was seeing past that, I think, was ultimately what led me there. And when Xen was getting less popular, I was 14 or 15 years old. I think AWS stopped officially using Xen or migrating to KVM around that time. And before that, Xen was even still obscure because people had moved to KVM more effectively.

And that ability to not be blinded by religious debate over technologies, I think, is a really powerful thing.

There's many of those in the industry today, and I think it's important to stay a little bit humble about it because nothing is all good or all bad. There's good parts and then there's bad parts, and you can take the good parts from everything and merge them all together to make something great.

Rachel: We as an industry moved away from bare metal hypervisors. Now CISOs will tell you container isolation is impossible. How do you sell into learned helplessness? I guess this one's for you, Emily.

Emily: We've spent the last two years refining that. I think that there's this brownfield and greenfield opportunity around isolation nowadays, which is the core container use case. And then you have this new GPU use case. Let's talk about inference and training and these neoclouds.

And ironically, the problem is still the same. How do you guarantee security and allow people to consume that in a way that you can guarantee? And I would say that, too, a lot of the movement around AI agent sandboxing and Mythos and all of these things are actually making it easier for us to articulate to CISOs that we didn't have 18 months ago.

So we really did a lot of thought leadership and sharing around containers or a list of processes. Don't be confused. But I think that it's been an evolution. I think the misnomer of containers being a word to describe something that does in fact contain that are this entire industry a disservice because we have a misconception of--

Rachel: There's a hole in my bucket.

Emily: Oh, I know exactly. But I put water in it. There's no water left.

But I think it's been a challenging movement for us, really. But I would say, one, that those who have a bit more sophisticated understanding of security, and that's typically highly regulated, large enterprises, large SaaS providers, understood what we were doing way earlier than I think we thought. We didn't have to do as much convincing as we thought.

But I think we're seeing a huge movement on the industry itself with the AI emergence. AI was still happening 18 months ago, but not to the extent of it's now not nation-state actors that can make this level of impact. It's Jane and Tom down the street, depending if they have enough tokens.

So I think that the idea of that has made this industry a little easier to break into, is that preventative really is the only way for you to scale against something that moves faster than the speed of any human can.

Whether you want to argue that there's marketing around some of the grandiose declarations of what this Mythos model can do, the simple fact is that you are now allowing something that is non-deterministic, either in your environment or other people are pointing it at your stuff, and you actually cannot stop something from happening. It's going to take a while.

So my risk model is different. It's changed the narrative.

Rachel: Now Mythos has been wonderful for prioritizing these conversations, which I guess we really needed.

Emily, you came to this world from people and ops, not engineering. At what point did you get comfortable calling yourself a tech CEO? And do you think the industry has that framing backwards?

Emily: It was really funny early on. I remember a moment when I was whiteboarding. I don't know if you remember this, Alex, with you and Ari, and you both called me technical.

And I had this moment where I had to stop and be like, whoa, because these two women are arguably one of the most technical women I've ever, I mean, people, not even just women, I've ever been engaged with. I think it's a hard question. I think it's hard to call, what does it mean to be technical? I don't actually really know. I've had debates about this. I've posted on LinkedIn about this in the past. It's like, what do you think it means? Over time, when I have been part of the tech industry, I was in financial services before. You could argue there's tech people in financial services. How deep do you know accounting standards or assurance or what have you?

And then in tech, it's software programming, those types of things. What I think I realized in my role, particularly if I am partnered as a founder with incredibly technical human beings, is that my value becomes understanding, pattern recognition, strategic influence, pain, people, because we're selling to people, regardless of all these, we're talking about software, but we're talking about buyers. How can I connect those dots for Alex and Ariadne so they can do what they do really well and the team really well, which is to build an incredible industry-altering technology.

So I've redefined that myself as, am I enabling that? My job is, I think also Alex and Ariadne described it to me early on before I joined, was we want you to be the conductor of the orchestra. Can you make us all sound good in harmony? Or are we all just fluting and tromboning at different times and it sounds a mess.

So I find my ability to be technical and learning things. I spend a lot of time learning from our team.

Alex and I just did a session even a week ago on AGI so that we're talking and orienting an industry. I don't pretend to know the things that I don't, and I'm very comfortable admitting when I've hit my capacity of understanding. And as long as knowing what you don't know is very prevalent, then I can be as technical as I need to be, recognizing my skill set is much more valuable in other places of the business because Alex and Ari and the team are going to be the ones to dive in the rabbit hole of the intricacies of the different types of hypervisors and syscalls and all of that. It would be a detriment to the business for me to know the same level of depth. We're supposed to round each other out. So I've changed my understanding or need to feel self-conscious about that. I did for a long time, not necessarily here, but over my course in tech.

It's like, wouldn't I? And I had a mentor tell me, never say you're not technical because that's just not true. You are limiting what you can learn by saying that out loud. And I realized that I just represent the opposite.

If we're having engineers learn how to lead people and hire well and create good strategy and correct harmony and retention, then we expect them to learn that. But I would argue it's as equally difficult as a different part of your brain. So why can't I then plug into the layers of the stack and learn type 1 and type 2 hypervisors and all the things that allow me to speak on behalf of the company?

So it's been an evolution, though. It's not to say you don't have that imposter syndrome moments, but it's much less now because we're just such a great team.

I think it also helps to have people like Alex. We work together all the time, who respect my gifts as much as I respect hers.

So there's never this peacocking of what I do is more important or valuable. I've never felt that way, which I don't think everyone gets to say that. So I think having a healthy appreciation for our gifts is also really helpful.

Rachel: The decision to build a control plane in Rust was both technical and, it seems, a statement. Was there a real debate about that choice or was it obvious from day one?

Alex: I would say there really wasn't a debate. I think it was really obvious that Rust is the right choice for this. It's actually really fascinating. Programming language choice is just so complex right now.

We're very plugged into the cloud native ecosystem and everything is written in Go, and it's that thing where everything's written in Go because everything is written in Go, right? And it's literally like, oh, I'm going to have to rewrite everything if I'm going to use Go.

Same thing for C. When you're dealing with low-level C things, it's very common for people to go, well, I'll just use C because it's written in C. What I realized is I wanted to build something very for thinking and also utilize something that would benefit the way that we develop our software.

For me, Rust is not about memory safety in the typical sense. It is an important part of it, but it's not the only part of it. I think it's about the way that you develop.

Ironically, we didn't really predict this at the time, but it's actually probably the best language to code gen through AI or to get help with AI from, primarily because of its rigidness and its ability to give good compiler errors.

A lot of my friends are Rust compiler people and they just blow me away with all the cool stuff they do. So it really wasn't a debate from that perspective.

And then also, everyone writes their kernel or their whatever in C. And I strongly believe that it is necessary to pick the language that's right for what you are doing. I have never been someone that is very religious debate about languages.

In fact, I'm kind of a program language nerd. I like all of the languages for what they are. But I also know that I need to pick the one that makes the most sense.

By practice in IoT, I was mainly in Java and Kotlin, not the languages that you would typically associate with someone who really likes systems programming. But that is what I was doing, and that's because that was the right tool for the job.

And when you're developing a hypervisor, anything that interacts with a very complex system, you need that kind of safety, you need the wrappers and the ability to do that kind of stuff really easily.

But more importantly, I needed predictable performance. Performance was the most important part of this. If the performance sucked, it didn't matter what I did.

It's not that Rust is fast. That's not the case at all. Rust is no faster than, in fact, it's often slower than JITted languages.

The benefit of Rust was that it was predictable. I knew that if I wrote this code this way, it performed that way. And that was super critical for what we're doing.

There's no surprises. There's no garbage collection. There's none of that. Everything is very predictable and statically analyzable as to what's happening at any given time. That was super critical.

Rachel: I think that's why it marries so well with CodeGen because the memory safety is almost a byproduct of the fact that it forces you to think through the system architecture up front. And that makes you write really good prompts. And it just has these knock-on effects all the way down through the pipeline. I'm not religious about programming languages, but I have invested in a lot of Rust companies because of those particular advantages.

Alex: Yes, and I would say I think that most people hire their engineering teams based off of primary language needs. I see Rust jobs, I see the UI industry TypeScript, and I think that is a natural consequence of the way that we teach our engineers. But I actually think that it's the wrong way to hire.

Although I need an engineer who knows Rust, what I really need is someone who's a domain expert in whatever I'm trying to do who can also learn Rust. And it is a byproduct of the thing rather than the thing itself.

And that is a super critical component of how we think about our usage of Rust because our language is just a way of writing. It's not the thing, right? And Rust in particular allows you to step out of its bounds really easily. And you have no_std and other things like that that allow you to not even use the standard library, so you're basically just writing C. And that understanding that the language is really the features of the language, not the language itself, is really a critical component of how you think about it.

Rachel: It's a really powerful lens. It's thinking about the first derivative of the problem.

Rust can be taught. Business skills, people skills can all be taught, but do you have a genuine insight into the system? Do you have a genuinely novel take on how this problem can be solved?

That's the thing that's hardest to find, both on the technical side and in investing.

Speaking of investors, you go into fundraising, you're an all-female co-founding team, you're in deep infra, you've said publicly you felt a certain amount of intimidation. What actually happened? Where did VCs surprise you and where did they disappoint you?

Emily: It's such a layered question, but there are a few things. I think the hard part, it's almost like I wish I didn't know the stats going in, because I think there's a bit of that psyching yourself out before you even start. We knew it was going to be hard, but I think the stats are less than two percent of VC funding holistically goes to female-founded teams.

And I think when you do the math and you look at how many startups actually even get funded, you're like, oh, no.

Rachel: 70% of that goes to Anthropic and GPT.

Emily: Exactly. So you're like, this is bad. But I would say I was pleasantly surprised and also had really funny moments of just, wow, that was so unbelievably cringe.

From start to finish for our seed round, I think we were out for maybe seven weeks or so. It was pretty quick. So I would say based on the time horizon of when we went out and closed, we were very fortunate and grateful. We definitely hustled.

Rachel: I'm so lucky I got to meet you then.

Emily: Yes, yes. We had a great moment of overlap. It was wonderful.

What surprised me in a good way was, and I won't just suck up to you because you're on the podcast with us, but I think there were people who genuinely appreciated the problem and genuinely wanted to see us succeed with it and cared that we were different and saw that as an advantage. And I think that was really wonderful. And when you have those little hits, I think as you're going through and getting rejection along the way, which of course happens, it helps you reorient.

The other thing that was really, I think, fortunate about our situation is we were really supportive of each other. It was very hard. During that time, I got hit first and I got to bring in Alex after that.

But she was really calm and patient when I would be trying to figure out exactly what words we should be choosing, how we should be positioning stuff and learning the real feedback.

Like someone genuinely cares and is trying to give you advice on how to be better versus, I think in deep tech in particular, you get this thing that happens where the VCs don't want to be honest, they don't understand the space. And so they'll say things that if you weren't able to step back enough, you could over-rotate what you start to do and what you start to pitch to accommodate something that's not relevant. So that was a really interesting experience of these people get it and they want to help me. And so I'm going to go adjust here.

And these people don't get it and it's actually not about me or they don't want to invest in anything in this area. It doesn't mean it's not relevant. It's just that there are people who like vertical SaaS, so that's not us. So I think that there was a lot of learning there. We did get some hilarious situations where the story I tell because it was just one of the most hilarious was when we were pitching, a VC started Googling Kubernetes and started telling me what it was and that I should have Googled it before I started my presentation. Awful. And I think in those situations, you just learn this sense of thick skin, because you're like, excuse me, that's incredibly rude. Thank you so much for your wise...

Rachel: Please mansplain to me. My resting bitch face is world class.

Emily: Haha. And then afterwards, I remember telling Alex because she wasn't on that one. I'm like, that was just so rough. But you just have to laugh and not let it mess you up because I think when you know that, statistically, you're going to have to have more meetings than your male counterparts.

And statistically, even in deep tech, it's harder because it's harder to relate to what we do versus there's a widget on my app, come look at it, versus, hey, let's talk about low level above the hardware infra.

So it took some time, but we learned a lot. We didn't have the right pitch right away. When we look at our first pitch deck to the end, it's a completely different deck. And I think that is great. That meant that we learned what to hit along the way.

But it was fascinating. So I would say overall, it was not a bad experience. It was really stressful.

And I would say going in, recognizing how hard it was going to be, I think was more of a psych out than, like I said, I wish I didn't know. Because it turned out to be a fairly successful raise for us. And I would say pretty quick.

But going out, we had a lot of fear that this was going to be a long road for us. And we also had all given up our jobs and steady income. And none of us were generationally wealthy, still or not.

So we had a time bound that if we couldn't figure it out, we were really scared we wouldn't get an opportunity to build this. So thankfully at all, we're still here and building and all that. But I think during it, there's just a lot of feels going on.

Rachel: So many feels. People try to multitask it. They try to do it while they're doing sales and company building. And it's like, no, no, you've got to single track this one. It's a beast.

Emily: You do. And you have to speak to VCs different than you speak to people you're selling to. And if you conflate them at the same time, you can start to pitch incorrectly. Even when we were transitioning from VC to sales, we had to have this moment where we're like, who are we talking to?

So the way you position and talk about values is entirely different. So you can really trip over yourself if you're trying to smush your brain into two paths at once. So it was quite complex.

But I will say, Alex knows, it is not my favorite part of my job. Fundraising is not. But I think I've learned the most about myself and your resilience and having conviction behind your ideas and the belief in what you're building and your team that you really start to just feel what's important.

Rachel: And it turns out you're really good at it. So congratulations. Job well done.

Emily: Thank you.

Rachel: More work is your reward. Haha.

Emily: There were days when I did not feel that. But it turned out good. We're all doing what we're supposed to be doing here, but you don't have to love all the things you have to do.

Rachel: Which is a perfect segue. Alex, you had a decade of full-time corporate experience before you were old enough to drink, you madwoman. Does that shape how you think about what it means to be a junior engineer?

Alex: Absolutely. I think I have had to watch myself on this many times because my experience is so different than everyone else's. And I have to remember that there are people who do software engineering as a job, and it's just a job.

Rachel: They start in college because their parents told them it was a good idea.

Alex: Exactly. To be honest, that was hard to come to terms with because I had a natural bias, because I was one of a few of my friends who were the same age as me, who were all open source developers when they were 11 or 12.

And I brought them along my journey. I was surrounded by people. So it wasn't just me, but it was also the people around me who were with me on the journey. So I had a really messed up view of what this should look like, to be completely honest, going in.

But I think that with the rise of AI, there's a lot of talk about junior engineers, and I just saw a really interesting video of someone giving a commencement speech who got booed because she was talking about how, I think it was maybe journalism or something, AI is completely changing the field and everyone was like, "Well, we're about to be junior in this field and we don't feel like we have a place." And I think that's a genuine problem in software engineering right now.

The thing is that we have to realize that the vast majority of the important skills that someone needs to be a senior software engineer or deeper in that level of the stack requires experience.

When I first started in the corporate world, I was completely stupid. I designed my own tasks. When I was doing open source, it was whatever I wanted to do. The time commitment was whatever I wanted to give it. I could work on whatever I wanted to work on, and suddenly that was not the case at all. I had actual things and tasks that I needed to do.

I just remembered in my head the spreadsheet, the first time someone ever gave me a task list. I remember it was an emailed Excel spreadsheet of the list of things I was supposed to do when I got back from summer camp. And the important part that I think is interesting from that experience, though, is that I learned what it means to be a junior engineer while still knowing all the software skills, but needed to learn all the other soft skills that you need to have.

And those are the critical things we need to be teaching people. It's how to talk to a customer, how to talk to an end user, how to talk about tech in a way that doesn't confuse everyone.

I'll never forget the person that I worked with. I guess I kind of reported the sales when I first started in tech because I was in a lot of sales calls, and that was a really cool experience. It must have been really awkward for the people who were joining sales calls, and there was a 14-year-old on the call.

But I learned a lot of those soft skills, and I never will forget the VP of sales telling me, "I don't have any clue what you're talking about. You need to dumb this down for me." So I refined that skill a little bit, and that was really critical.

I don't have any great answers on what to do when AI is writing all the code, but I will say that engineers tend to completely forget the amount of soft skills that are actually required.

The job as a software engineer is hardly coding. It's really gathering and knowing what to do and being able to turn things into actionable changes.

And if that's editing a prompt or it's actually writing the code, it almost doesn't matter. And I think this is something that Emily really opened my eyes to a lot, is how much of people matters, and what's missing in engineering orgs is often those people skills.

I hope that if everyone is right and this replaces the job that people have of just writing code randomly, the soft skills become the most important thing. But the cynical part of me tells me that people will probably miss the entire point.

Rachel: Well, as an English grad, I'm glad to keep my competitive advantage for as long as humans will exist, honestly.

Alex: Yeah, absolutely.

Rachel: Your Series A was led by M12, Microsoft's venture fund. That's a strategic signal as much as a financial one. What does Microsoft get out of this? And what do you get out of Microsoft?

Emily: That relationship was really special to us for a few reasons. I think when you're building something so low-level and, I would say, emerging, because the isolation space was, until we talked about earlier, a lot more defined now that we're looking at AI agent sandboxing, all these types of things. Back when we were working with them, which was over a year ago for the Series A, they had a deep investment thesis in exactly this. They had been looking at WASM and other isolation technologies and were very bullish on us.

The first meeting I had with them, just an intro, they were like, "Just to be clear, we want to lead your Series A." They knew. And I always laugh about our partner, James Wu. I'm like, "Wow, I thought you were kidding." He was like, "No, it was not." Because you don't usually see this, "No, no, I just want to make sure we are on the same page about this."

So what was really great, I think it was outside of you, because you really understood what we were doing and had familiarity with Xen too, is that they really knew the problem and they saw it coming. I think in a lot of ways, we were trying to bring them from Kubernetes around, like an orchestrator and containers, I'm going to bring it over here and why we care. We didn't have to do that with them. They were like, "Oh no, we see it."

So what was really nice about that is it was, I would say, established conviction around the space that we believed was coming. And they saw it too from, I would say, a large corporate angle, which has great value for us because obviously Microsoft is so prevalent in industry.

The thing that we get, not only from the validation piece, which was really important to us at the time, is access to low-level developers. It's very rare for people to know hypervisors.

They have Hyper-V. We literally had, I think, an element that we wanted to dive into. I don't remember exactly what it was, Alex, but we were able to call Microsoft and say, "Hey, we saw this one engineer actually did this. Can you have them call us?"

And they literally went and found it. It was a five-year-old thing that they had done five years ago, but then popped them over. And we had a conversation and addressed an issue like that.

I don't think you can have many investors that have pull on technical talent, particularly as specific as we have, the way Microsoft does. And they've been wonderful with introductions and support of our team. And James is great, our partner.

We've been very lucky, I think, to have that type of partnership that you don't always have. A lot of times it is just the intros or orientation around the, I would say, ecosystem to some extent, but they've been very specific on the technical components of helping us too. So it was definitely a wonderful match for us, but I think we both realized it early on.

Alex: I think I can add on to that. I remember telling Emily explicitly that Microsoft was a big deal to me. And it's interesting because I'm not necessarily a Microsoft fan, but I consider myself maybe an Apple fan or whatever.

And what was interesting to me is that they have always been very technical in a way that other people have not. Even at Google, I would say Google's problem is that it's just a bunch of nerds kind of making stuff. And Microsoft is like, "What if we actually poured millions of dollars of research into hypervisors or whatever?" So Microsoft Research in particular is incredibly interesting.

So for me, that was very valuable. But I'd say the other thing is that we were overcoming at the time the whole "Why Xen" thing. And the funny thing is that Hyper-V is basically Xen.

Rachel: Yeah, it is.

Alex: It's essentially the same thing. It even shares a lot of the concepts and...

Rachel: Paravirtualized rather than hardware accelerated.

Alex: Yeah, and I think that there's even somebody who worked on Xen ended up going to work at Hyper-V and that's how it was created. And then there was also the point that Emily brought up with the person that we went to go find. That person worked on Xen and then got hired by Microsoft to work on Hyper-V.

That access was super important for us because, A, they inherently knew that what we were doing was valuable because of that experience. But also, it was very good validation for us, as Emily said. And for us, it was a mental leg up as well, I felt.

Rachel: You did build for Kubernetes first. And I remember in our very first conversation, it was like, so GPUs, AI isolation. It feels like the bigger long-term opportunity. How do you think about where Edera sits in the AI infrastructure stack five years from now?

Alex: It's an interesting point because I don't think we really know how everything's going to shake out. Things keep changing, preferences keep changing in terms of the exact stack we're going to end up with.

But what was really important to me is that I didn't just build vaporware. I built a stack that was meant to last.

And what popped in my mind immediately was when Steve Jobs announced Mac OS X, which used Next Step technology. That was supposed to set up Apple for the next 20 years, right? I think of our stack as just as fundamental to computing in the sense that we're trying to build something that lasts however we end up going.

And we talked a lot about Kubernetes, but the fundamental technology was not specific to Kubernetes. The thing that we built was what I consider to be the front end of the system for Kubernetes. And then Edera itself is just underneath and can adapt.

We're actually seeing some AI companies that are not using Kubernetes. We see companies that are using nothing but Kubernetes. And I don't think we will know where that will all shake up.

I'll say it's 10 years plus into Kubernetes at this point. I don't think anyone would say that Kubernetes is perfect. But nothing is.

So I think that we built our technology to last and whatever people end up using. We have people that are using things like Slurm and other things like that as well.

I think it's a very interesting component of the stack because it is highly applicable to whatever you're doing. If you just need a container or you need a VM or you need any sort of sandbox, the Edera platform can provide that using the same APIs that we provide Kubernetes for. And that amount of flexibility and non-rigid architecture and design was super important to me as we developed our technology.

I think that hypervisors will never go away. And the primary reason for that is that we are seeing an adaptation of the way that we build software to where people are thinking in more compartmentalized systems.

That's basically what containers was trying to do. But containers was sort of like, we think that the idea of a container is cool, but we didn't really do all the backend work to make it as cool as it could be. And ultimately, I feel that that backend work is the most critical component because it's an enabler for a lot of things. And that means performance, security.

Mythos and all of that is super big driver for us because that security aspect, you have to design systems with that amount of security. Especially with things like non-deterministic computing that you see in AI, that stuff scares me to death.

And I gave this talk that I'm very proud of about the layers of the stack and how we get too comfortable with the layers of the stack that we have. And so we start to build layers on top of layers instead of thinking fundamentally and holistically about how we're building things.

And the power of Edera is that it's so low level and so essentially down to the hardware that it really can apply in so many different scenarios, but also it's a true reduction of the amount of stuff that you have to deal with.

Rachel: It's like digging out the basement to replace the foundation and the house is watertight for the next 50 years.

Alex: Exactly right. It's that hard work that no one really wants to do, but ultimately when done, will set us up for the future.

Rachel: Quarter of your renovation budget, no one can see it.

Alex: Yes, exactly. Precisely.

Rachel: What are some of each of your favorite sources for learning about AI?

Emily: Well, my answer is Alex. She is my resource.

Rachel: Everyone should have their own Alex.

Emily: No one can have that though. I'm the only one that gets that.

Now, what I think is interesting, because someone like Alex is so thoughtful about what seems to be real versus what can be more like the marketing hype of things, because I think it can be very easy to get lost in other people's depiction of what's happening and go down that loop.

So I find finding really sane, reasonable people who are touching this. And it's not just Alex. We've got folks internally that I really lean to.

We've got an even channel internally called Ecosystem. And in our Ecosystem channel, we share a lot of resources across with each other where we seem a really important knowledge about specifically A or the ecosystem in general, so it's kind of a compilation of the minds that I trust guiding me on the journey.

So not as helpful to share externally, but I'm sure Alex can do that. But she's my person.

Alex: I enjoy teaching people about what's real and what's not, because I think I have a pretty good bullshit filter. I'm pretty honest when I say that something is not real. And I'm pretty honest when I think that something is real or could be real.

I think Mythos is a great example of that, where there's this big debate about, is it real, is it not real? And to me, it's not about Mythos itself. It's how the impact of the hype is going to cause a change in behavior.

Rachel: It's almost quantum. The fact that we're talking about it affects the phenomenon we're talking about.

Alex: Exactly, and I think that's an underrated part. I'm kind of tired of people talking about how it's not as good or whatever as it was hyped to be, and I think that's total nonsense, right? I think it's changing the way we're thinking about things.

I'm embarrassed to say that the way that I learn AI is primarily from other people on the internet talking about it and complaining about it. I would say, obviously, I'm transgender, and the trans tech community is very cynical about AI.

And I think it's actually very helpful for me because I get to see a different perspective and then I get to see what's actually happening because I have more context and I can pull out the realness of things.

The other thing is that my learning style is very hands-on. I have to see it and use it to feel it, right? And to get it. And so I do a lot of really crazy stuff.

I'm not one of those people that has 40 Mac minis and I'm running totally local AI or whatever. But for me, it's very important to try to use the capabilities.

And also, we happen to be in a domain, by the way, with hypervisors that the models weren't very good at. Either understanding or thinking about, we're also very different.

An LLM is good primarily because it's trained on things it's seen before, but no one has ever seen our Rust control plane for Xen, and no one has ever seen it do the things that we're trying to make it do. And so if we use it to find bugs, it's okay, but I can see its actual limitations that way because I'm doing something completely unique with it. And so I think that has been the primary way that I've been able to filter what's real and what's not is by looking at it and actually trying it.

And I think that I also can fundamentally understand that computers are thinking sand, right? It's literally sand that thinks.

Rachel: Look at it. It's got anxiety.

Alex: Yes, exactly. And so I have that context to be able to go, this thing is telling you what you want to hear. There's this famous image of a meme, I guess, online of someone asking to LLM, are you alive? And then it says, I'm alive, and then everyone's freaking out. And it's literally in the back end just auto-completing, basically.

We have to be realistic, but we also have to know the impact of the hype going back to Mythos and why it doesn't really matter what's real or what's not sometimes. It's the reactions that we have to that means, right?

Rachel: Humans also hallucinate.

Alex: Yes, precisely.

Rachel: All right. I'm going to make you co-prime ministers of the galaxy. Everything goes exactly the way you want it to for the next five years. What does the future look like?

Emily: I'll take my first go at it from an Edera lens. I think we've spent the last couple years, and again, we're very grateful for the market allowing people to see and feel the problem that we've been explaining, but that we as an industry, particularly security and infrastructure, truly embrace the proactive, actually built-in components of security and not continue to talk about it and actually do it. Obviously, Edera, what we've been pushing is, I think Alex described it really well. It's why are we not just fixing the foundation? And we have the answers now.

Let's stop talking about it. Let's stop performative security. Let's just go do it.

But it's cheaper to do it the other way. It's just the pain. But if I'm the ruler of the galaxy, as you've given me, bestowed onto me in this moment, in five years, should we start to see this movement? Let's just say this is the start of what we believe to be a fundamental shift in how people perceive their infrastructure and the importance of that, particularly as a society.

But five years from now, we will see Edera running underneath what I would consider to be some of the most important infrastructures in, I would say, the world. Whether that be the government that protects secrets, whether that be the large enterprises that hold all of our most valuable information, that we get to be behind people's ability to truly believe and understand and feel that we're protected. And that it's not just this reactive game.

So from a simplistic stance, I believe that that's possible. I really do. I don't even think that that's just a dream in my galaxy ownership moment here. I think that we actually have a real shot at that now, particularly with a lot of things happening around us. So that would be my overall grand declaration.

Alex: I think the one thing that I would add on is I really want people to look at a solution like Edera and start to think what things that we are not thinking deep enough about.

We have a tendency in software engineering to only do what is familiar to us. And that means building of layers. And I think Kubernetes clusters are an example of something where things are so complex that it's just comical.

And I want to bring simplicity to the stack. And that is a huge component of what we are able to do in a secure and performant way, is bringing that simplicity to how you think about the security of your system.

And so my add-on to everything Emily said is I really hope that platform engineers and people who are building these systems see Edera as the thing that made things different in a positive way and made the system something that you can actually understand. Because I think that's an underrated part of what we're doing is that containers are a very complex thing to use. And if you have the isolation and the low-levelness that we have brought to the table, I can actually whiteboard exactly what the application is without having a thousand boxes. And I think that's something I personally believe will benefit the industry as well on top of everything that Emily said.

Rachel: Why do you hate Figma?

Alex: Haha. I don't know. Figma's pretty great. But I've seen some people do some very interesting things with their architectures. Haha.

Rachel: With your position as Guardians of the Galaxy, your official vehicle is a generation ship. It's a ship that takes longer than a human generation to reach its starborn destination. What will you call each of your generation ships?

Alex: I immediately thought of WALL-E when I heard of this, and so the ship's name and WALL-E is called the Axiom, and I think it's actually a very interesting analogy. Just go look at what WALL-E is all about and you'll see why I think it's an interesting analogy for all of this.

Rachel: And also the Axiom is perfect for you, looking for the simplest, most basic statement.

Alex: Yes, exactly. And the other answer that I had in the back of my mind as I was thinking about this was I'm really into For All Mankind, the sci-fi show.

And Pathfinder is an interesting ship name to me because the way that I think about software engineering is pathfinding. I try to take a leap and then think about how I'm going to get to the next leap and then the next leap.

And I think that is ultimately what drives me is that kind of pathfinding thing. And I just always thought the name Pathfinder was super cool.

Rachel: It is. It's really good. Emily?

Emily: Well, there's two, but I'm going to go with the one that is behind me, but I will say it, which is Believe. I am a huge Ted Lasso fan, but also the other, either Believe or Manifest. And they have the same, I would say, ultimate spirit, which is this sense of either belief in yourself or belief in a greater good or belief in change.

The same thing, manifesting in my view is doing things with intentionality to get to that goal. Some people hear manifestation, they're like, oh, you're just gonna wish like a genie in the it's like, oh, this is gonna happen. But I consider Edera a product of manifestation. We sat in a room and we said, this is where we're going, and we made every decision in line with that. So if I'm gonna be going up to the stars and on this colony ship, if I want to find cool things and reach the stars in all those ways, I would want to do it through a continued belief and manifestation of what lies ahead and what we can find. So that would be mine.

Rachel: I believe. Alex, Emily, thank you so much for coming on the show. What an amazing journey. Hope you come back again soon and good luck with the next thing.

Emily: Thank you, Rachel, for having us, really.

Alex: Yeah, I appreciate it. It's been great.