Spite-Driven Engineering: A New Blueprint for Cloud Security in the AI Native Era

Transcript

Olimpiu Pop: Hello everybody, I'm Olimpiu Pop and I have with me one of the inspiring young technologists that want to do something with purpose. Alex Zenla, the CTO and co-founder of Edera. Alex, can you please tell us a bit about your purpose and what Edera wants to do for us to be safer?

Alex Zenla: Yes, absolutely. Thank you for having me. I'm Alex. I've built software for over, I guess, 12 years now. I guess important context is I started really young, so my first intro into anything programming-related was actually probably around 10, if I had to guess. My dad worked in IT at a university, and when I would go to work with him, I would mess around with the computer labs and stuff like that, and that was probably as early as six or seven. And then slowly, I gained an interest in it.

I remember I had a hand-me-down laptop, and I installed Ubuntu on it, and that was basically the start of my like off-the-beaten-path ways of thinking. So, I kick-started my tech career at 14 and started working in the Internet of Things. That probably could be its own podcast episode of its own, but basically, I got an email one day from someone random on the internet that liked my open-source projects I was working on, and it turned into a paid job for me right at my 14th birthday.

So, I have basically been working full-time for 12 years now. I did about 10 years in the Internet of Things, and then in late 2023, I was kind of looking to more or less retire from Internet of Things and go do something else. I have always had a passion for dev tools and software systems and operating systems. Ariadne Conill is one of the maintainers of Alpine Linux, or was, and created APK-tools and Audacious and a few other software projects. She was someone that I was friends with, and I was working on this idea at Google about a hypervisor that could actually run containers natively.

So, Ariadne was very interested by this because she was working at Chainguard, she was one of the people that created Wolfi—or the main creator of Wolfi—and then that kind of spun into its own project. She was one of the people who wanted to go do something different, so we started a company together, and then that has eventually formed into Edera. We build a technology called Edera that is all about isolating containers and also VMs and system images from each other, and we have this concept called a zone that allows you to run isolated workloads inside of a safe virtual machine. It's very focused on enterprise needs and enterprise use cases. Performance is a key thing of it, so we focus a lot on performance and making things fast, and also accessible to the enterprise.

Don’t accept a flawed status-quo - Improve it! [03:46]

Olimpiu Pop: You mentioned Ariadne, and in your presentation at QCon, you mentioned her again, mainly because of a philosophy. And I think that's quite important because everything comes in anger, as you said it, and that's spite.

Alex Zenla: Yes, this is the part that I most believe in, I think, as a fundamental philosophy of how I develop software. The slide in particular was about spite-driven development. When I was working at Google, my goal of building Edera's eventual technology was trying to solve a problem that I was honestly a little bit annoyed hadn't been solved.

And quite a lot of Ariadne's past comes from doing that kind of development from frustrations or from things that could be better or trying to look at the world and go like, "I'm not satisfied with this, and I'm a little annoyed that it works this way". We are very comfortable in software making things complicated. We're not very great at simplifying things.

And spite-driven development is kind of my way of thinking about the world differently, and when I get annoyed with the way that something works—I'm not trying to advocate for the "not invented here" syndrome or anything like that—but what I am trying to advocate for is something of the sense of, when you know that something's not working, you don't have to make it work in that way, right?

My biggest example that I gave in the talk was all about operating systems because everyone uses Linux. But I can tell you that Linux is not perfect, and no one who claims that Linux is perfect has ever done any sort of development in the Linux kernel. There are all sorts of problems and things and edge cases, and it's a great kernel, but the way that it fundamentally works is breaking in some certain ways. And we have to fundamentally accept that and start thinking about different ways to develop.

That doesn't mean throwing everything out; it means changing your architecture, getting more familiar with different layers of the stack, and really trying to dive in and solve problems in areas you don't understand. When I started working on kernel-level and kind of virtualization stuff, I had absolutely no idea what I was doing. But what I did is I did not stop. When I hit a roadblock, I tried to understand.

And actually, when Edera was first created, I think LLMs kind of existed, but it was like baby LLMs, and so I didn't really have that kind of assistant to ask when I hit a roadblock. It was quite literally just me hacking away and brute-forcing things to get our hypervisor to work. And I think that that is an underappreciated part of software, of like really trying to break things and trying to develop software in a way that, even if you don't know something, you can just push forward. And now today, I mean, some of the things you can do with AI-assisted coding make it really easy to get involved in stuff that you have no knowledge of.

I think there's a lot of questions of maintainability and stuff like that, but ultimately, you can build working things in stuff that you've never understood. But I think an underappreciated part is also—and this is how I use LLMs personally—I will literally just like take a spec of some sort, throw it into Claude, and then have Claude explain to me all the information that I need to know, and I will actually take that in. The problem with vibe coding these days, and why I think it's somewhat incompatible with spite coding perhaps, is that at the end of it, you have to understand what you did. And that is a critical part in, I guess, the feeling of gratification you get from spite-driven development, I guess.

Accelerate your understanding with LLMs [08:09]

Olimpiu Pop: Well, probably the motto of this part of the discussion is to vibe or not to vibe, right? So...  But I think you're right. I have the same feeling because as you go up the ladder and you have more and more responsibilities, it's harder to hack away, especially if you're going into areas that are evolving quickly. And I'm thinking now of the growth of the cloud-native, because everything now is native. And I will not even mention the JavaScript ecosystem where you blinked, four more other libraries appeared, and all of them are the best.

But the benefit of having assisted development, not to call it vibe coding or anything like that, it's if you start, as you said, from fixing a problem, either for you or for a broader community, you have quicker gratification. You don't have that part where you just do a bunch of stuff and then you get to the point where you don't know exactly what's happening, and then you have to understand and then you forget everything. So then you have more chances to get upfront, especially in parts that are properly documented.

And I spoke to multiple people lately, for instance, one of the conversations I had was with Gunnar Morling. He developed the first library in Java that is almost zero dependency for Parquet. And it's, at least from my knowledge, is one of the first open-source libraries that is started from scratch with LLM help. And it allows him to have proper incrementation quickly, and that came from the fact that Parquet is very well documented, and it allows you to see where it goes. Each of them started with a design document that allowed him to understand what's there and all the things that are happening, so I think it's very important.

The other fear is it's like the beginning of the App Store, when people were like just—you just went somewhere and you just duct-taped everything and then, okay, these things have holes, but I don't care because I have to be there. And those are the things that I think we have to be careful with.

But all in all, I think it's a very good moment. For instance, I managed the other day to put together something that was scraping online, doing notifications, and I used a cloud provider I never used before. And all of them happen in a short period, but then I just said, okay, most of the things I know at a high level, now walk me through them, challenge me, grill me in terms of to see what's there. And I think that's important because it was double gratification.

On one hand, I had a dopamine effect of I managed to finish something quick, but I also knew the concepts and I know how to build it. I'm just thinking about all the system design interviews; now you actually can build stuff in one, two hours, and that's quite achievable. It's nice, as you said, looking at a problem and extending the Girl Scout or the Boy Scout rule, make the code a better place. But, as you said, you started from a need. And during your presentation at QCon, you did mention that some of the inspiration, or your security philosophy, started from Minecraft. Particularly, the layering of different points and the way how you can look at it. So, where are we currently in terms of the cloud-native stack?

Too many abstractions layers [11:21]

Alex Zenla: Yes, absolutely. I guess one thing I didn't mention in the intro is that Minecraft was a big part of my childhood, and really the catalyst, I would argue, for my actual interest in programming rather than just shell scripts and sysadmin stuff. It was sort of that moment that I can identify where I really shifted my thinking and really wanted to build actual software. It helps that Minecraft, it still is, written in Java and is a JVM application, which makes it fit for lots of reasons to be introspected and analyzed and modified. It taught me a lot of really interesting things.

The biggest thing being layers of the system and how you think about system layering. And actually, you know, one thing I didn't go into in my talk very much is Minecraft as a game architecture also has layers. I like to think of it as like if you take a layer of the stack that I showed and then you have a microscope, you could actually see thousands of other layers in there, but you have to break it down at some point.

But the main thing that I focused on was about system layers and this idea that hardware is built upon with firmware, and then firmware is built upon with a kernel, or in most systems actually a virtualization stack of some sort. And then you have the kernel, and then you have something like containers, like runc, Docker, containerd, all these different layers that are running the actual container itself, which communicates with the kernel. And then you have Kubernetes, and then you have your application or maybe other orchestration. And when you start to do this, you start to really forget what's at the lower layers of your system.

I would argue that the vast majority of people who are going to listen to this podcast are probably pretty squarely focused on what I consider to be the application or application orchestration layer, which is where a lot of cloud-native sits. Everything in cloud-native is an API. Everything in cloud-native is about, "Can I call your HTTP API? Can I call your gRPC API? Can I communicate or scrape data or shovel data from one place to the other?" And to be very clear, there's nothing wrong with developing at that layer. It's a very important and critical layer of the system.

Unfortunately, I think that we have created too many layers in our systems. And that means that the cloud-native developer is sitting all the way up here, and the kernel and the system is all the way down here, right? And that is a huge problem because the kernel and the systems involved in delivering the kernel subsystems have a very clear and critical impact on every layer above them. If the Linux kernel sucks, everything else is going to suck.

And this is a real problem. The thing that I was trying to focus on in my talk that you mentioned was about the security problems of this. And the thing is that when Linux breaks, and the security of Linux breaks, everything above it is a complete wash. If you have a kernel CVE, it doesn't matter how secure your Kubernetes cluster is because the kernel is shared across the entire Kubernetes node. So suddenly, the security just completely breaks down.

And fundamentally, we have forgotten how important this is, and we've gotten very comfortable with creating layers of abstraction. But if you really look at the best and most secure way to do things, it's usually by reducing layers, reducing attack surface, reducing those possibilities.

And this is then kind of my fundamental way of thinking about the system. And I give a ton of examples in my talk of a lot of cloud-native engineers will work around things that they don't understand in the Linux kernel. They will, you know, use higher-level abstractions that may not actually be perfect for what they're trying to do. And that's because when you sit at that layer of the system, if you don't understand the kernel at a very fundamental level, then that becomes a real problem for how you develop your software.

I particularly talked about the constraints. So every layer of the system that we add constraints any layer above it. The kernel and the way that the Linux kernel works heavily restricts how the applications above it have to act. The reason why we have containers that work the way they do is because that's the technologies that we've been able to glue together in order to make the Linux kernel suitable and for a container-like system. But you can perfectly well design a different kernel that has different aspects and different ways of thinking and would fundamentally improve or change the way that containers run. And that's what we've tried to do with Edera, which is developing a virtualization system that actually natively understands containers, not in like a shoehorned, "Oh, I'm just going to run a microVM" kind of way, but like really fundamentally diving down into what a container is and building technologies directly for that.

The security risks of the monolithic Linux kernel [17:01]

Olimpiu Pop: So at some point you have to look critically and rather than just building on top of a shaky foundation, well, taking a step back might be very beneficial in multiple cases. I know that there are plenty, but let's see if we look at the current stack, what would be, I don't know, the podium of main criticalities that system engineers, architects, whatever you want to call them, people that have to care about these things should be aware of.

Alex Zenla: I think these days with things like Mythos, you need to be at least aware of the kernel more than ever. And if I had to change my talk a little bit and I could go back and improve it, the one thing that I would do slightly differently is I would acknowledge that people don't completely ignore the kernel. The way that people interact with the kernel is maybe through something like eBPF, right? It's maybe through something like, I don't know, if you're a Linux desktop aficionado or Linux laptop aficionado, you might have to manage sensors or fan controls or something like that, right? And people do interact with the kernel more than I think I gave them credit for in a sense.

But understanding what backs that stuff is a completely different thing than interacting with it. You need to understand why a process is a fundamentally insecure thing that can leak things between other processes in Linux in order to build secure systems. We think about it from a very basic level, but we don't really think about why the Linux kernel can't do anything about it.

And not to spoil it, but the main reason why the Linux kernel behaves the way it does is because it's a fully monolithic kernel. Everything in the Linux kernel is effectively one single shared process when you hit kernel level. There's lots of caveats and things there, but the important thing is that, for the most part, it is true that memory from the kernel can leak any other process's memory, right? It has full ability to control the system, and so a compromise through a system call is a very severe problem because it can literally impact everything.

And I think that is something that needs to be critically understood, and not just at a trivial like, "I understand that like a file descriptor can leak" level, but also understanding the myriad of ways that the systems we have in place don't really help; Like a namespace, for example—a Linux namespace does not prevent you from leaking a file descriptor from one process to the other. Linux cgroups don't perfectly control the resources that a process uses because if I make a certain system call, I might be able to impact another task in the kernel to behave differently, which then won't fully account for the CPU and memory resources that I have consumed through that.

So if you try to use these things for full multi-tenancy in a security model what they're not designed for, you will run into a ton of problems. So I think the kernel is something that more people need to know about, and I don't think you need to go that much lower than that for the most part. And going back to our AI discussion, it is easier than ever to understand the kernel. Claude in particular—and I'm sure Codex and these other models—Claude in particular, I'm pretty sure has the entirety of the Linux kernel source code inside of its model. You don't even really have to go fetch kernel code to ask it questions about the kernel, it just knows. And of course, yes, check your sources, AI can make mistakes, of course, but if it's even 90% correct, you have learned 90% more than you knew, right?  And that is, I think, a very critical part of working at these layers, is not being afraid to study them even if it's something you've never interacted with before.

Work in symbiosis with LLMs [21:33]

Olimpiu Pop: Well, I think that, as I mentioned, that's the easy part of it because I'm just thinking how my research looked like five, six years ago when I had like tons of tabs open, notes taken all over the place, and then trying to just put together and making notes. And now it's something very linear, and then you just provided and it's—let's say it's easier to go down the rabbit holes because you have an elevator that takes you up or down depending on how you want to do it, and then it's quite easy to just try it.

But going back, squashing the two discussions together, as you said, it's quite easy to understand concepts that it's harder to grasp, even if you're just building on top of university knowledge or basic stuff as I am doing currently. From my point of view, when people are going in ground that they shouldn't go, they don't fully understand it, they don't have the patience on looking all these kind of perspectives, and then Reddit is full of, "Well, I don't know how to code, but I built a company that is producing that amount of money", and then five weeks later you see that, okay, asking for help because everything is exploded. How would you advise somebody to mitigate these kind of things? I'm asking you because you're in that level where it's not good to play with, I mean, if you play with the kernel, things can get quickly in a dark place.

Alex Zenla: Yes, I think you have to have a little bit of humility to understand what you actually understand versus what you think you understand. I think people's first instinct with vibe coding and stuff like this is like, "Oh, I'm going to vibe code something", or, "I'm going to use AI to get rich". Like your example of all the Reddit stuff, that's a lot of what people use it for, and I think that that is just such a bad way to look at it because if you're trying to do a get-rich-quick scheme, that was a problem beforehand and usually a scam, and just like today it is as well.

So, you need to understand that like you can't just do things and think you know things and then succeed with that and run with that. I think the humility part is understanding what you actually know. And this is a big problem with Claude and AI in general, is it's really hard when you don't know something to know whether the information you received is correct or not. Which is why I think it's important to never just write code blindly with AI.

I'm not suggesting that people should go build a kernel module with AI if you have no knowledge of the kernel. In fact, I would say that this concept of one-shotting or whatever is just such a ridiculous idea because I think that AI has to be an assistant. And the reason for that, that I fundamentally believe, is that you need to be able to learn alongside of it.

Here's the thing with one-shotting and this idea of just developing something once and then reaping the benefits after, which I think is where a lot of those, "I built something cool and it's making all this revenue and then the next day it combusts", right? I think that the difference is you need to be able to prompt and understand over time how things work. If you've ever actually run Claude in an assistant-like way, you will notice that it gets things wrong 20% of the time, 30% of the time.

But what I always think is interesting is that you can learn from its mistakes because although AI can lie to you, right? It can be incorrect, what can happen though is if you actually apply the thing it said in the agents and then try to run it and it doesn't work, that proved that it was wrong.

I'll just give a very funny example that literally just happened a few hours ago to me. Somehow in macOS, I managed to break the open and save dialog across my entire system, which I learned is because it's a shared XPC service, like a shared service across all of the applications on the system in macOS, and that's for security reasons. Somehow I triggered an infinite loop in this process. Well, I was building an app with Claude to do some analysis stuff, and I told it, "Hey, my open dialog isn't working, can you please try to fix?" And because it couldn't think of any possible way for this to happen, it just completely spun out and it was doing some really crazy things like offloading the loading of the save panel and the open save panel to another thread and then presenting like a loading dialog, even though it was never going to actually load because the real problem was that the macOS service for it was broken.

If I didn't know enough about macOS to know that it's an XPC service and thus I should go inspect it, I would have been sitting there going like, "Well, everything's broken and everything's just ruined", because Claude could never imagine that macOS would be broken in this way. You need to have that knowledge still to be able to dive into this and actually inspect and debug your system because when Claude is wrong, you need to be able to tell it what's wrong. And so you just can't blindly trust everything it says, and I think of it as like a symbiosis, right? Like you are feeding it information, it's feeding information to you. Just like if you tell it something and it thinks it's wrong, it's going to tell you—well, with the new model it'll tell you, the old one it used to lie to you, that's what they claim at least—well, if you do that, you also need to be able to check its assumptions just like it checks yours. So that means that if Claude tells you something and it doesn't sound right, interrogate that. You don't just have to blindly let it sit there, right? And I think that is the best way to think about how to use these effectively.

The GPU bottleneck: rethinking AI hardware and multi-tenancy [28:08]

Olimpiu Pop: Okay, so take responsibility for what you're doing, check it, create the guardrails around it. But because we touch on AI, two years ago I think, or three years ago, I don't remember exactly, on stage at the Linux Foundation Keynote, they put a big love sign between AI-native and Kubernetes. Obviously, Kubernetes is known for providing orchestration for a lot of workloads, so obviously AI will benefit from that. But, because you mentioned that we cannot go deeper than the kernel, obviously we can, we can go to the bare metal and then we know that the GPUs were never considered for these kind of things. Obviously, like most of the things in computing, they were considered for something else, particularly doing a lot of visual calculation and so on and so forth, and then some brainiacs have realized that that can be used also for machine learning, and then they started using it. What kind of worms is the AI-native hugging the cloud-native brings to the table?

Alex Zenla: Yes, it's an incredibly interesting thing that we spend a lot of time on at Edera with GPUs, and the thing that I always talk about is that the same GPU driver in the Linux kernel that I use for playing games is the same one that people are deploying to do these GPU workloads and training and all that kind of stuff. And that is insane to me. First off, they don't have to be the same, and you have all sorts of reasons why like sharing the rendering system of the GPU with LLM-related stuff and the complex architecture of GPUs, they are actually fundamentally different in so many ways. One of them being that data is extremely sensitive on GPUs. The vast majority of times, the data loaded into a GPU is either a proprietary model—think Claude—or user data, which should be private, which isn't realistically ever private in quite a lot of scenarios, although I will say Anthropic has done a really good job at that.

And I think that it's incredibly interesting to me that the same thing that was rendering my Minecraft all those years ago is doing this job. I had a really interesting discussion with someone about rendering. As my Minecraft background probably shows, quite a lot of my friends are game people, mostly game developers, and one of the projects that I've worked on a little bit is SDL3, if you know what that is, it's kind of a really cool graphics thing and basically it's like DirectX but for Linux and other operating systems.

The fundamental thing is that security is not a concern in gaming, like at all.  If it renders faster, they would much rather have no security. I don't know if you've ever met a real high-performance gamer, but they do not care in the slightest about the security of their game. In fact, there's a huge pushback against DRM and for good reasons in gaming, and anti-cheat stuff and all of that, which does reduce performance considerably in some cases. The fact that this is what's being used in order to do these very complex calculations for LLMs is insane.

I actually think that Google's TPU approach and other systems like that are going to be the winners long-term because they are fundamentally built for the task. You mentioned the AI-native and Kubernetes. Kubernetes is used so heavily in the GPU space, and it logically makes sense because GPUs are fundamentally a scheduling problem, Kubernetes is intended to make scheduling easy. Anyone who knows the internals of Kubernetes is probably also wincing a little bit because it's not necessarily clean.

In fact, there's a dynamic resource allocation in Kubernetes which is designed to basically try to solve the fact that Kubernetes had no knowledge of complex topologies of devices and the complexities of GPUs. I think that cloud-native is a great thing for this AI-native sphere, but going back to the layers problem, maybe the layers at the kernel aren't really suited for it.

As a great example, a GPU is kind of just a single-tenancy system. All the memory is all shared, if you've ever used CUDA and you try to run multiple CUDA things at the same time, that's kind of all an illusion, basically. It really doesn't understand this concept of processes or separation of any sort, even technologies like MIG don't really do all that much. So you have this fundamental problem that one tenant in a Kubernetes cluster that has access to a GPU can—and quite frequently does happen—cause a fault on the GPU and break the GPU for anyone else using it. So workloads often run inefficiently because they can't actually share a GPU.

On top of that, when they run on the container-based system, if they're not using something like Edera or Kata Containers or something like that that actually isolates every container into a separated secure zone, the big problem is that a GPU compromise can impact other customers as well. These are the types of problems you have when you repurpose one thing for another in a domain where it doesn't make all that much sense. And this is why I think systems like TPUs and systems that work at a completely different layer are going to succeed more in this space because they are fundamentally designed better for this kind of scenario. The line that I always use is GPUs are built for rendering, not for LLMs, and that's the truth of the matter and that hasn't changed.

My hope is that if we're going to continue on this "GPUs are still used for LLMs" thing, we need to consider the fact that maybe just maybe we should be developing custom kernel drivers, custom software, even running on the GPU itself—the orchestration of the GPU tasks and stuff like that—even building it into the hardware to be multi-tenant. Or we're making a huge mistake, and there's recently some rumors, just rumors, that Apple is considering adopting Nvidia for their use of Gemini that's coming out, and that Apple has agreed to the use of confidential computing, for example, on Nvidia GPUs. Apple is very privacy-conscious, they care a lot about user data privacy, and you can see that how they built their private cloud. I think it's really interesting that they require confidential computing, and this is news actually. When this podcast comes out, we will know whether or not that was the case. 

Tech sovereignty and regulation [35:48]

Olimpiu Pop: So probably the TPUs versus the GPU as you mentioned is a good example of not taking the status quo for granted and challenging it and improving it, so that's a good one. Amazon has their own project and others as well, but probably from my point of view, I'm thinking Amazon and Google are the ones that in this space have the best outcomes when it's—we're discussing about hardware, so I'm happy to see these points and especially that most of them are being used by the likes of Anthropic.

Google has a big partnership with Anthropic, so that means that actually that will improve the whole ecosystem, so that's very fortunate. I was rather surprised when I was watching your presentation, which I highly like because there were other guys in the public, for instance, Victor Petersen, who was talking about the way how the European rules and regulation is trying to bring a better software for us, and I was surprised that somebody from across the pond, somebody from the West Coast of the United States to be more precise, was quite happy with what we managed to achieve here in Europe. And that's something quite important because now it feels like it's a bit of a struggle, if not call it a fight, between Europe and the US, and it's nice to see technologists like you, and there are others, that have the same feeling. So, how do you look from that perspective as a CTO, as a co-founder, about the regulation and the way how Europe looks at it?

Alex Zenla: Yes, no, it's a really interesting thing. I am definitely someone who believes in proper regulation of things that impact society, recognizing people's individual freedoms, which is a very natural United States thing to say. I fundamentally believe that regulation of cyber security is extremely critical because cyber security in particular is something that it's one of those things you have to force people to do it. I've worked in a lot of scrappy startups. Edera does not really fall into this category of being a troublemaker in this regard because I have more control over it, but there's a lot of startups that don't care about security at all, even in the slightest.

And what I have witnessed personally in the Internet of Things space is that a lot of those companies, it doesn't matter how small you are in some industries, you might control very critical and important data and systems. And so I think that regulation of this sort is super critical. And I also think that there is an—and this is sort of more of a European regulation in general—there is a delicate balance. Like there are some things that have come out in regulation in the EU that I disagree with, but there's quite a lot that I agree with. Some things I disagree with, for example, are any anti-encryption related stuff, which I don't think passed, but is just an example of things where people have proposed things that I don't think are great.

But making companies do something that they should have already been doing is a very natural thing for people to step up and do. And when you talk about software sovereignty in general, I think it's just super critical that the Eurozone in general has its own ability to, A, create startups that function and deliver well, and deliver software that works for the people. And that's true for every nation. I think the United States in the same way should have the ability to create software that works for the people. You only need to look at our tax system here in the US to recognize that that doesn't really happen.  And so I think it's a huge win politically and socially when these kinds of things pass and actually protect and help society.

Olimpiu Pop: Okay, so take responsibility for what you're doing, check it, create the guardrails around it, and learn. But because we touch on AI... I will close our discussion here with this very thin bridge across the Atlantic, and let's hope we can build more because it's—we are all living under the same sky in the end. Thank you, Alex.

Alex Zenla: Yes, thank you so much. I really enjoyed the conversation.

Mentioned:

• Simple DirectMedia Layer (SDL3)
• Confidential Computing Consortium
• Building Hardwood with Gunnar Morling Podcast
• Secure Software Development Framework
• Cloud Native Security Challenges Podcast with Marina Moore