E198: How Unikraft Launches AI Agents in

Speaker A: Welcome back to Open Resource Startup Podcast. This is Tun from Essence VC and my co host Robbie from Modern Technical Fund. We're so stoked to have Felipe CEO of Unicraft to be on our pod. Unicraft is next gen cloud platform, so welcome Felipe.

Speaker B: It's a pleasure to be here. Thanks for having me.

Speaker C: We definitely want to hear about the founding story for Unicraft, but I think why don't we do some very quick level setting in the beginning so maybe talk a little bit about what Unicraft is and what Unikernels are and kind of like what that tie is and then we'll get into the full Unicraft story.

Speaker B: Sure. Unicraft is a cloud platform that you can install either on a bare metal server or something like an EC2 instance. And then based on Docker files, anything you define, any workload will start in about 10 milliseconds and the platform will auto detect whether it's receiving or doing anything useful work. And if it's not, it'll scale it to zero and then it'll resume it when the next requests come in in under 10 milliseconds. And so that makes it so that it looks like everything is on all the time, but on the background there's nothing idling. And then because that's the case, you can bin pack a huge amount of micro VMs onto single servers. Some of our clients are running like 100,000 of these things on a single server. And so you get really superior economics. And then there's some things related to that because the system is snapshot based, so you can do branching and checkpointing and a lot of funky things. Everything in sub 10 millisecond scales.

Speaker A: Cool. So I used to work on Docker and Kubernetes, so I'm very familiar with this sort of things. But I'm sure most people probably don't even know what a unikernel is. So can you maybe just even tell us what is Unicraft and explain your open source project? What is Unikernel and how does your tool come into play?

Speaker B: Sure. So Unigraph, the commercial product, is a number of components coming together. So what gets installed on a bare metal server is a controller that is closed source and proxy and various components. And one of them eventually is the image. So the virtual machine that actually needs to run. And while we can run Linux kernel VMs, we can also run something called a unikernel. And the Unikernel is a virtual machine but it's constructed in a meaning, if you know what it is that you want to run, like you want to run a web server or a go function, then you can actually build not only the operating system but the entire distribution so that it only has the lines of code needed to run your particular application. And so instead of running like uh, 4 gig Uboom 2 VM to run a go function, now maybe you're running a 5 meg virtual machine to run the Go function and that gives you savings obviously.

Speaker C: Very cool. So now that we've kind of like level set a bit on that, why don't we talk a little bit about the history of the project? Because it's kind of a unique founding story. The project was around for some time, was part of Linux. The company came many years after. Can you give us some kind of like history and background?

Speaker B: Yeah, sure. So, um, many years ago in the galaxy far away, I was a researcher and uh, in the beginning we were part of a research project called Virtual Routers. And this was supposed to be let's take a network router and stick it in the virtual machine. And how do we make the I O of it go fast even though it's inside a virtual machine? So it was a performance and efficiency project and then from there it turned into hey, let's not only do software packet processing but actually can we take any Linux binary and stick it in the virtual machine and have it go fast? And the whole thesis was is it really the case that if I want the security virtual machine I have to compromise uh, performance? And we were also trying to battle back then this was the wave of Docker had just hit and containers were secure and containers were fast and whatever. And so we were putting out these sort of back then hot take paper saying hey, my VM M is more secure and faster than your container. I think fast forward to today if I say that nobody's going to think that that's a hot take anymore, especially with the recent CBEs. But back then it was sort of was somewhat controversial and so given your

Speaker A: started probably as an open source project if I remember correctly. Tell me, like how does your open source project or your tool, what does it do and also where you grow the usage and community from that Because I feel like you probably learned a lot of lessons given from 2021 starting the space, this is really early and doing this as well. What is your journey like from that open source project? What did you learn to morph into the product that you're selling to? Sure.

Speaker B: So If I pick up where I stopped, the story was we have these virtual machines that are specialized, right? But they were handmade and we were hand making them for each application. Imagine you spend three months building a Python specialized virtual machine and then you want to run a web server and you have to do it over and over. So we thought, hey, let's probably build an SDK to make it as automated as possible to build the specialized virtual machines like you basically maybe specify in a Docker file this is my target application, and automatically out comes a virtual machine that is specialized in, ready to run. So that's what the Unicraft Linux foundation project was that we created seven or eight years ago. It took a long time to mature because ultimately we wanted it to be roughly Linux API compatible. And then in 2022 is when we created the startup with the idea of applying these things to the cloud. We want to you like, we're pretty sure what the cloud primitive should look like, what the cloud, uh, should run. But uh, you know, if we were to sort of take a step back and rethink it from an efficiency and scalability perspective, what would that look like? And we tackled the VM part and very naively we were like, hey, let's take that specialized virtual machine, turn it into an AMI and take it to AWS and it'll start in 10 milliseconds, right? Because that's what we're used to. And then you start in AWS, it takes 30 seconds to get started and it consumes way more memory because a cloud platform ultimately is all the sum of the components. And so that took us into a rabbit hole of let's take those same principles of efficiency and apply it to controllers and proxies and whatever. And once we were done revisiting all of that, the product was born.

Speaker C: Basically I want to back up a little bit to donating the project to the Linux foundation because it's not the most common path for companies that are going to be open source. And I'm sure there's kind of like pros and cons. What was the thought process around working with Linux? And at that time did you know you were eventually going to start a company or were those kind of decision points separate enough?

Speaker B: No, it was never a goal. We didn't know. I mean we're definitely square in the research arena. Although we were part of an industrial research lab belonging to the NEC Japanese company and we were doing all of this research. NEC is like uh, a Siemens or General Electric company massive in Japan. 100,000 people, and they have data centers and all kinds of things. And we were like, hey, this will improve the efficiency of data centers. But NEC is very Japanese, very hierarchical, and they were like the Google in the 90s. And then they started to become a system integrator and the business unit started telling us, this sounds really good, but we don't have the technical expertise to adapt and maintain what you're doing. You might want to take it open source. Like, I literally had discussions with the CTO of nec and he's like, listen, take it open source, make noise, then we'll bring it back in. Which sounded like a really weird way to get adoption within nec, but that's what we did.

Speaker A: And so a lot of people, when they open source the code, the hope is to make noise, but they don't make as much noise as they hope. How did you make noise? Saying, I'm a unicorn, open source project. I don't think it's going to be the most biggest wave everybody will be talking about, because unicornal, even working on Docker early there, has small waves, but it never really grew a big wave. And so what was your way? What did you learn to make the noise with this? What are some key things you've done really well?

Speaker B: So, couple of things. Um, first, we were leaning a lot on these wow numbers. I can start things in 5 milliseconds. Right. I can run your web server using just 5 megs. I can scale it to zero and bring it back up. And I can run thousands and thousands of VMs in a server where the common understanding is that you can only put 50 VMs on a server. Right. And now I can order of magnitude do it better. So that's one way of generating some level of noise. The other is regular work of basically over the course of a few years doing hackathons and getting people to sort of code on it and get excited about it and building a community little by little.

Speaker C: All right, so you open source it and maybe take us back to, like, when exactly you open sourced it. Was that seven or eight years ago?

Speaker B: Yes, that was a while ago. I think even longer. Eight, uh, nine, ten years ago is when it started, but then we matured it over five, six years. Yeah.

Speaker C: And then so you open source it, give us kind of like the trajectory. So, like, to Tim's question, did it take off immediately? Like, you had a lot of these kind of like SOUNDBITE type things that you're kind of pointing people at, like, did it just grow over time or were there Kind of moments where you gained a lot of momentum.

Speaker B: Um, it grew over time with spikes, as you were sort of suggesting. And uh, some of the spikes had to do. We were publishing these sort of research papers and some of them would hit hacker news and then you get these spikes. So a bit of both. Yeah.

Speaker C: All right, so it's growing and then like give us a sense of at what point you started thinking, okay, there can be like a company behind this as an opportunity to like build a paid product. Like at what point did that happen?

Speaker B: Yeah, so that started happening back in 2021, a little bit into 2022 as we were starting to get growing, uh, frustration that NEC wouldn't be the right place to adopt this stuff. And we felt that it did fit. Technically, it's just like the politics of a single company were sort of hindering the adoption of it. And at that same time NEC started instituting some sort of spin off type program where you could sort of apply to be able to take some of this tech out. And uh, maybe they could be investors, maybe not. We said hey, let's just take this and run with it. And we looked for external VCs in the EU and US and that's what led into a precede round. Uh, back in 2022 you mentioned NEC

Speaker A: and these big corporations looking to use you. And I think having an open source is way more easier to adopt. I totally get it. But oftentimes I think when you think of new technologies, even back in the days of Docker Kubernetes, these large corporations are never the first one to adopt things. Right. They always wait for someone else influence or start using it in a small way. Right. Talk about at hacker news, talk about at conferences. You know the typical thing is dockercon was really, really popular back then. Kubecon, therefore. Next. I really haven't heard of a unicraft or unicornalcon. I guess I feel like that's sort of the momentum and the sort of way the community even evolved is quite different than some of the other type of technologies. And so can you talk about maybe like how does adoption usually occur? Is it truly larger companies that have a huge amount of efficiency miss gaps, looking to use unit kernel or do some other patterns where people do start using a kernel and much earlier than others.

Speaker B: I think, uh, it's a bit of a mix because ultimately the sort of the open source unicraft is an operating system project and so it's not really opinionated as to what kind of company would use it. So for instance there's um, the Microsoft Hyperlite team that is using Unicraft to run virtual machines for wasm based M on Unicraft. So that's pretty big. But then there's people in the automotive world sort of picking it up because uh, Unicraft itself is super customizable and in the automotive world efficiency and few lines of code for certification and security matter. So there's a little bit of everything. Um, in our case uh, we use it to go to the cloud with it and we also do Linux VMs as well on the platform and there the use cases are also varied. Sometimes it's agents, sandboxes, headless browsers, databases, functions.

Speaker C: So a lot of times when we see open source companies they'll have like the project that's been around for a bit and maybe has some traction, momentum but usually not this long where you know, it's established. I'm sure there was a lot more kind of like data and just like user understanding to figure out what to build for like a paid cloud product. Can you talk about maybe like what you started with like when you were trying to figure out like okay, what's the commercial product going to be? Did you have already a good sense from the community? Did you target it more at the like enterprise mid market users? I'm sure there was a lot more data there. So like how did you think about like what the commercial offering was going to be in the beginning?

Speaker B: Yeah, so in the very beginning I think we were targeting tech savvy companies that could understand the huge potential not just now of the specialized virtual machines but the entire platform. Right. So if I give you a funky box that can start everything in 10 at least and put everything to sleep and wake up magically, do you understand the potential of that? So we were looking at tech savvy companies and Prisma was our first customer and they were wanting to run like millions of databases in as little hardware as possible. So that's kind of how it got started. So you know we weren't necessarily targeting a single type of company. I know some open source projects. For instance, if I'm squarely doing uh, next js then I know what kind of, that's a very well defined community. But when you're doing an operating system project that's a horizontal community ultimately not a vertical one. So we had to sort of extrapolate uh, from the open source as to what the use cases would be and what's the histogram often for horizontal platform and the ones that sort of turned up initially were databases and functions and also build environments and test environments that need to start quickly. But then more recently obviously agents and headless browsers kicked in as well.

Speaker C: I think with, uh, specific examples are really, really helpful because so many open source founders really struggle with where to start with their cloud product. So you mentioned Prisma. Uh, can you talk a bit about how you even kind of found them and got in contact with them? Were they just heavy open source users? Did you do a bunch of interviews in the beginning to figure out who you were going to kind of like build for? Like, what was that process like?

Speaker B: The process of meeting Prisma was, uh, I was at a conference in Berlin and one of my investors said, hey, that's Soren over there, you should go talk to him. So I'm like, hey, uh, Soren, I'm Felipe from Unicorn. He's like, yeah, I know about you guys. Actually I've been looking into what you're doing for a bit. He's a very savvy technical founder and he played with Firecracker before some of the basic components. And he's like, because I've done that, I know how hard it is to actually build a production system based on that. And that's how the conversation got started with them.

Speaker A: That's amazing. And so maybe talk about how does a, um, platform or very technical product even adopt this? Because I think a lot of people, we learned how Docker gets adopted, we learned how Kubernetes gets adopted. Obviously if you can build a virtual um, machine image, it probably feels just like any virtual machine you use. Right? Is that the only consideration? When you're using unit kernel, it's really hard to tell what are the other things that people need to change or learn differently. When it's fully actually trying to adopt a unit kernel way, is there such a thing or is it just a VM and you don't have to think about it differently at all?

Speaker B: Yeah. So to one extent, yes, it is a virtual machine and yes, it can get packaged into an OCI format or an ami, et cetera. Right. So the outside world looks the same. The only thing with the new kernel is for generic workflows. It works best when you know at compile time what it is that you're going to run. Because what that allows you to do is make sure you only pack in the operating system modules that are needed to run that like you, uh, know if you have the Linux API, you can reduce it down to the system calls that you're going to need and nothing else and then you go deploy it and it runs and hopefully nothing else gets called because if you don't have the syscall available the whole thing will crash. So it works well for defined things like I want to run a database or a web server or these functions for generic workloads like a headless browser or an agent. On our platform we use Linux kernel because that's just so generic that you don't know at runtime what is actually going to be used. So that's like the caveat let's say

Speaker A: and given many platforms like I'm sure Prisma probably supports extensions, I can actually even redis has LUA scripts, right? Like all these platforms typically is not just run SQL queries alone anymore. There can actually UDFs all the kind of things. From the sound of it, you should know exactly all the possible dependencies and build that in to way to use unit cropping unit kernel or do folks almost increase the surface here incrementally based on whatever new features they build? Is there a different way to even I guess sort of iterate on this unit kernel of virtual M machine images? That's not just adding another app to get installer with a typical Linux thing. What's the trade off typically? How would you try to add stuff very quickly? Add stuff only when you have a lot of surface area. I wonder, do you have any sort of best practices folks have come up with already?

Speaker B: I mean guideline number one, when one of our clients uses our platform, they have the option of using a Linux VM or unicornal, right? And how do they decide number one, if it's going to be, as I was saying, a very generic workload where at runtime you have no idea what it's going to do like a headless browser, a full desktop environment or an agent. Then go for the Linux vm if you have an idea like I'm just going to run go functions that are going to be doing log analysis. Um, then maybe a unikernel is a better option. You don't need all that additional crud. That's sort of the guideline. Ultimately you have a docker file to specify what it is that you're doing. You have a little label to say I want to use the unikernel or not that that's like the only from a UX perspective the only difference.

Speaker C: So I'm sure too AI workloads have been very top of mind in how those fit for unicraft versus others. Can you talk a Bit about maybe like what's specific about AI or agent workloads and what makes Unikernels or Unicraft like a really good fit for those.

Speaker B: So not so much Unikernels in that case, but the platform as a whole. Because as I keep saying, like an agent can do anything. And so you don't want to run that in the Unikernel is going to try to do things that the Unikernel doesn't support. That was, you know, because it was built that way. But the things that are very obvious about agents is please do not run them in containers or isolates because that's really bad. So you need to use a virtual machine, right? This used to be a hot take. Hopefully it's not anymore these days. The other thing is they are often ephemeral. They run, they then go do IO or they get put to sleep or a human is waiting to provide more input. So you don't want to run them when they're idling. So it'd be good to scale them to zero. And if they scale to zero, obviously it'd be good to wake them up right away, not to introduce delay when you wake them up like in millis and you need to wake them up from the state they left off. You cannot lose state when they go back up. Right. And then the final part is like huge scale. So even for a single service, you may be running millions and tens of millions and hundreds of millions of agents and you probably don't want to dedicate an entire data center to it. And especially these days with the prices of memory and CPU chips. So compute efficiency is really, really important going forward.

Speaker A: So maybe talk about the new agents use cases. I know computer efficiency is certainly important, but I think people are so new to agents at this moment. I feel like how do you measure efficiency? Is it just purely to actually compute? Because agents are not really compute bound. And I think a lot of people look at sandboxes. There's a variety of vendors coming up, but there's no really a really good benchmark of what people actually care. A lot of sandboxes are like launch speed. But does everybody really care how fast your sandbox is launched? We don't know yet. Agents are pretty early in the conversations. And so when people come to you, what is probably the most important things that they're looking for? Is it truly just like, I can run a much smaller sandbox with you and that's it, or is the security attack surface actually much more important? Agents, can you maybe Summarize the biggest value prop that's maybe unique to AI coming into using your product.

Speaker B: Yeah, sure. And we are a platform for people who build agentic products and then offer it to the world. So we see a bit of a spectrum. So who's right? Well as long as they're a client, they're right. And some of them are just like a little CLI UX and some of them are offering full GUI based remote desktops scaled to zero. And so what's the right primitive for agents? So in terms of our value add specifically, yes, most of them do care whether the thing starts in 24 seconds or it starts in Android 100 millies. The fact that it's immediately up from a UX perspective and a user perspective, especially if a human is waiting for things. But also you're usually chain these things and so the delays can actually add up. And also when things take a while to start, it's not just a delay, it's taking a while because you're burning CPU starting things up. And that's not good. Especially when you're the provider of those agents and you're providing millions of them. That really adds up in terms of the bill. And then of course agents you should use virtual machines. And how uh, do you provide technology that is a virtual machine but still gets you these really fast and efficient semantics? Right, because the reason in the past people or even these days depending on who you talk to, use containers or isolates is because they're lightweight and you can do things quickly but you're sacrificing security. And so one of the things that I'm bullish about is like you don't have to do that. If the engineering is correct, you can have the strong security of the VM and sort of the lightweightedness that we like in containers and isolates.

Speaker C: So we've talked a bit about the few different trajectories and the project and company have had a number of different periods. Has this been a huge kind of growth moment because Unicraft was started kind of pre agents, pre AI. Can you talk a bit about what's happened from uh, are most of the users now building agents? Is this the main use case or is it still kind of that and

Speaker B: headless browsers has become one of the main use cases? Yes, although we still are in the space of databases uh, and functions and build environments because they're, you know, if it takes 30 seconds to start and 30 seconds to run, that's really inefficient. So it's good if they start right away. But yes, for sure. We're not complaining about sort of the tailwinds of uh, first it was headless browsers for us, to be honest, and then with that, uh, agents. But because our platform is a bit of a Lego fold for builders, it's often the case that customers who do headless browsers eventually do agents or the other way around. Or maybe they start with agents and then do functions and then do headless browsers. So it becomes a bit of a toolkit for the AI space.

Speaker A: Yeah. And do you view headless browsers use cases pretty much the same as agents in your mind? Like they don't need anything particularly different or there's maybe an overlapping core set of things, but then it diverges depending on actually as an agent, runtime or hosting platform versus truly just a headless

Speaker B: browser or I think headless browsers are the main work tool of agents.

Speaker C: Right.

Speaker B: There's nothing an agent, um, um, I'm sort of generalizing, uh, maybe hypervisizing a bit. But there's almost very little that the agent can do if it doesn't have access to a headless browser. It's its main work tool. It's like maybe a writer without a pen would probably have a hard time writing. Right. And so this is also what's driving the use of headless browsers. And in our case we cater not only to providers of headless browsers like browser use users and kernel and so forth and others, but even internally other companies that have nothing to do with that, but they want all of a sudden to have an agentic interface to the existing product. And now they need a headless browser because the agents need headless browsers, et cetera. That is also tailwind for us.

Speaker C: So the last year for sure, but like the last couple years there's definitely been this kind of amount of momentum and uh, like a number of companies that have come out that have talked about being kind of these next gen virtual MA or containers, whether it's E2B or Daytona. Uh, can you talk a bit about how you view the landscape? Are you looking at different kinds of workloads or the benefits of using Unicraft versus some of the others in the market today?

Speaker B: Yeah, I don't think I can openly say, but we're powering a few of those. I mentioned browser use and they do agents and we're powering them. So we see ourselves as sort of the infra for infra in that sense. Although of course because people want to Build agentic platforms on top of us. We need to provide a lot of the primitives that people are aware from those platforms, like checkpoints and branching and all of those things. Because then when people want to build, they expect those things to be there. But we kind of stop a little bit short of going out and saying, hey, run sort of directly on us, just like Daytona and the other ones will do. Now I see your question. I can still sort of speak a little bit intelligently about all of those offerings and what are the differences? And we do see a lot of people going from one to the other to the other one like run Differentiating factor is people do care about start times, so maybe they'll bounce from one to the other in terms of not only the agent starting fast, but also reliably fast. That's one of the things. But I wonder where this is all going to eventually consolidate because, uh, the differences, these are going to become base primitives. And what's going to differentiate a lot of these people? I don't know long term, I don't think anybody really knows. And is the right primitive the ability to SSH command into the agents or is the right primitive to have a simple desktop environment where you sort of control k a prompt into existence and it'll go do things and it'll show it to you in a gui? I think the market is still trying to figure out what the right primitive for an agent will be because right now there's a developer echo chamber. But the world of humans developers are a tiny fraction and these things apply to the entire world population eventually. Right?

Speaker A: So given the benefits we talked about, like Unikernel is fast, secure, all these things, it seems like there's no reason people shouldn't use it. I guess I'm just trying to understand for all these agent platforms or headless browser, all these other people even doing model inference providers, all these people are running a bunch of small compute units or sandboxes. What's the reason they haven't got onto Unikernel yet? Because they haven't heard about it? I don't think that's the case, but maybe they're not familiar with it. What's your major friction points still at this moment for folks that hasn't even gone onto this yet?

Speaker B: Well, uh, the same one I mentioned earlier, if it's for generic workloads, it simply is not going to really work very well. Agents and headless browsers are not ideal use cases for unicornals because you don't know what's going to run. So you're going to have to compile time, compile everything in, in terms of the syscalls of the Linux API. And now you are getting a little bit close to the Linux kernel because you've turned all the Christmas tree lights on. And then uh, what is the difference? You get diminishing returns. So that's one part of it in our case on the commercial side, as it turns out, a uh, lot of the games at the millisecond figures that I'm sort of mentioning all the time come from the other components. And that's sort of by design because we spend a lot of time optimizing the building a controller from scratch, all the other components. So you had millisecond end to end type semantics. But then the one problem was what happens if the application takes like 2 seconds to get started and it kills all of the performance you just spend your time building. And so we had to do a lot of engineering around snapshots to make sure that even if the application is slow, everything is fast. And once that's the case, there's no big difference between having a Linux minimalistic kernel in an application in terms of both are in the image and I need the image to start fast and we as a platform we need that to be reliably fast. Even though you may be running a headful chunky 8 gig browser or a 10 meg go function. Right, right.

Speaker C: So I'm curious if we can get into some specifics. You mentioned Prisma, you mentioned browser use. Can you talk about maybe like a couple more examples of users, uh, and like their experience before and after unicraft, especially for agents on like they were trying to run this kind of agentic flow and it wasn't working because it was chained to other agents because I feel like a lot of people there's so much value in what you're building and it would just help to like anchor it in a couple more examples.

Speaker B: Yeah, so a lot of the wow moments are when you get onto the platform and you're used to everything taking seconds and all of a sudden you run a command and it says here, I'm up in 9 milliseconds and I've gone to sleep already. And then you query it and it's like hey, I woke up and answered you in 6.7 milliseconds and it's just like immediately reactive. We've had both the types of reactions like wow, amazing, uh, or I don't believe it's true. And then uh, we get Feedback like we can't believe it's doing what you're actually claiming to do. Right. So there's a little bit of that factor. A lot of also the deployments we do are on PREM or byoc of people that are sort of grabbing the platform and building a massive service out of it. And in that case it also has to do with I can't believe I can run millions of these things and just out of a few servers. So to the outside world you are in effect running a massive server, but indoors you're doing it with sort of just a few servers, which by the way with the sort of economics that are happening these days around servers and memory chips and whatever is a good thing.

Speaker A: Since you live in this sort of in between infra for infrastructure. I feel like at least today in agent or maybe just GPU workloads as a whole, there's a huge amount of discussions what the future of all these ecosystems will be. There's a lot of investments in NeoLabs, Neo Clouds, New GPU architectures, the whole shebang of things I guess for you. Does any of that affect you at all? Do you have to watch everything beneath you and above you at the same time? Or I guess virtual machines as ah, a software virtualization and doesn't seem to need to care. I'm just very curious. Does the change of GPUs like TPUs for example or I don't know, maybe some other up and coming LLMs or diffusion models or non transformer models, does any of that affect you particularly? Or if it's just selling to infra for infra, just focus on the infra platform providers and that's kind of it.

Speaker B: No, we do keep an eye on that because some of our clients may say, hey great, I'm running all of these amazing uh, VMs that scale to zero, that are super fast, but maybe some of them need a bit of GPU and our platform needs to be able to provide that. So we do keep an eye on that. And I can get into the weeds of how are people doing GPUs uh, for VMs these days, but that gets a little bit technical. But we do keep an eye on obviously I say upcoming hardware. TPUs are old and GPUs are old and they've been around for a while but we're always keeping an eye out. Uh, is there a new CPU architecture that's going to have like 1000 cores as opposed to like 48 or 96 like today? All of that stuff is interesting to us. And yes, you're right because we're like a middle layer. We're also keeping an eye out above as to what do people need, because we also need to implement checkpoints and live migration and all this stuff that agents and other workloads need. So yes, we're doing both.

Speaker C: I actually do think it'd be interesting to get into the GPU needs for VMs and maybe also talk about where you fit in that like what your team needs to access, is it your customers who are the infra providers, they have their own GPU access. Like what matters to you and how do you work with your customers on that?

Speaker B: Yeah, so what we provide is the software support such that a VM has access to a gpu, very roughly speaking. And then that if our customers are running it themselves, they've been managing it, or we do dedicated hosts, in which case we operate that. The thing with uh, VMs and what I would really like, and what we're working on is, is I would like to have GPUs that operate like a CPU where you have like 100 VMs and they just pop up and all of a sudden they have a sliver of the GPU ready to go just in time. You know, when people support GPUs what happens is you take an entire GPU, you can at most split it 16 ways, the GPU is up all the time, it takes super long to get started and then it's just attached to vm, um, forever until it's not needed anymore. So it's not like the dynamics that you're used to with a VM and a CPU where you can sort of timeshare it in really, really short. It is possible and we're working on it, but it requires a lot of engineering, modification of drivers and things of that sort. But the state of the art is a GPU is not really shareable all that well. And it's not just in time thing, it's just like you get a gpu, the VM is using it and it just runs forever. Right. What I'm kind of hoping and what would be great is uh, of course it's not a big problem in that a lot of the GPU bound things like inference just goes out to the big boys, anthropic and OpenAI and you don't have need to run it directly there. It only matters where like an agent or a VM might need some more traditional GPU usage. Like maybe you're doing some video streaming and you need to do operations on the Video stream and then it's better to do on a gpu. Eventually, maybe inference at some point the models will get good enough where they can come back back to CPUs or at least some of them. And then in that case we'd be well placed to sort of pounce on that too.

Speaker A: So I'm curious how you think about your cloud platform because obviously you're like we mentioned, you're at the OS layer. So I think adding features, snapshotting, maybe even monitoring in some level, telemetry, these are all very understandable kind of how Amazon added EC2. First you need machines, you got to make sure that those things can boot. But after that it's a pretty wild west. Whatever you can Add. Amazon added S3, we're an investor in modal, they add a bunch of networking functionality because I think the workload and the use cases and audience definitely guides towards the features and things you add. And you're building such a unique set of customers here. I don't think we've seen that many players sell infra for infra. Right. So what do you think your surface area is like? What kind of things you will add to your cloud platform and what things you won't like? Would you have a database offering for example? Are you going to even have some other additional services that allows more people to build more type of workloads and more flexibility or stay below only certain things? I'm just curious how you think about that.

Speaker B: Yeah, and it's a good question. Obviously right now we're a horizontal platform and I think what you're kind of asking, uh, will you at some point go for almost like a hyperscaler play where you're going to have vertical products yourself? Right. Right now we're pretty much a horizontal platform, a technology based one and the surface area is pretty large because I know we started with like technically savvy companies, but we're also going after the kubernetes market where everybody's using warm pools, uh, like uh, provisioning for peak and those should be collapsed and we think we can help there. Uh, and every single enterprise has warm pools and even any company really. So the surface area is way more than just a few companies building pitless browser solutions. So we're kind of excited about that future. And in terms of like the roadmap and features, I think sure things like branching and checkpointing are around. But I think what really matters is can you do it at scale, can you do it reliably, can you do it in 10 millisecond scales. Can you grab like a 10 terabyte database and branch it off so devels can play with it and do it in 100 milliseconds? Like scale matters and speed matters and zeros matter. Right. When an agent can actually answer in a second, then the world explodes. When the agent was taking five minutes to answer, nobody was really believing that this technology would actually work. So I think our company cares a lot about making sure that all of these things work reliably at scale in production and super fast.

Speaker A: That's super interesting because unikernel is at the OS level, but all the storage and state it start getting to the EBS EFS sort of of sphere which is obviously operating system talks to, but your product has to expand there. Maybe it's the same question but related. How far do you go deep into this rabbit hole? Do you need all kinds of file systems and all kind of storage options that Amazon, Google, everybody provides with the same type of encryption on rest it can actually be pretty large product surface area to go for. And I wonder how do you decide, okay, let's stop at this. What is the way you help you guide the philosophies around this?

Speaker B: I mean where to stop, that's a tougher question. What to actually add? Ah, uh, that's based on sort of customer demand. And yeah, you're right, uh, on the file system side, because we're a horizontal platform, we have to be a little bit agnostic. We cannot say hey, this is the only block solution or storage solution that we're supporting all of our clients. If you think that's not the good one for you, then you are wrong. As a horizontal platform we need to support sensible a few of those cases. And so the platform, obviously when you have access to an entire host, you can mount S3, but you can mount other things. But then from there to the vm, we support things like EXT and virtio FS and a few things. And that covers most use cases with pretty good or reasonable performance. Right. So our platform not only supports vms, but also supports the content of the volume. And you can attach volumes to the VMS and you can also snapshot the volume volumes as well and you can branch the volumes and ah, you can do all sort of operations that you would do to a vm, you can do them to the volumes as well.

Speaker C: So I'm curious to get uh, some of your biggest learnings going from being on the research side for a long time and would argue probably even before that doing your PhD like you've always kind of been on the research side to moving to productizing commercialization, like being a founder. Like what have been some of your biggest learners?

Speaker B: Yeah, it's a good question. There are a few parallels in that you uh, need a top notch technical product and in research you need to have the best technical solution. If you want it to get published, you need to raise money. Uh, that's uh, researchers also part of the main job. So that there's some parallels. But then it kind of starts to break down because I used to think that getting a research paper published in a top tier publication was tough. But basically if you could have the best technical solution and you're a good writer and you keep at it, eventually it gets published, right? When you go commercial, those requirements expand to not just two, but like 20 of them. Not the least of which is having good timing and things you don't even control. But there's also pricing and landscape and competition and interactions with other products and speed of deployment and sort of just making sure that you can speak well about your technology and your technology is better than the others is nowhere near sufficient in the commercial world. And of course in terms of time, like a uh, researcher works really hard up to a deadline, like startup times, like you don't even sleep, but then past the deadline you slow down. When you're doing an actual startup, that intensity is pretty constant. You just don't have these moments where you can just take off for two or three weeks. So that's also a big difference.

Speaker A: What's the pros and cons of running this? I guess distributed team working infrastructure. You guys all worked at NECK in the subsidiary research side, right? Jumping into the build infra company. What has been like the biggest lessons or valuable things you learned, maybe even just a culture or things like that to help not just you but your team and know who to hire to get into the mindsets here. Is there any particular things you learned around team building or.

Speaker B: Yeah, so one of the things, I mean we cheated a bit in that uh, first researchers, top um, level researchers work remotely anyways because the odds of you having like the entire top notch team exactly next to you are not very high. So it was a very smooth and easy transition. Especially when the pandemic hit, everybody's like, can we actually work remotely? We were like, we always work remotely, what's the big deal, right? So that was one part. And so building a remote company was like the most natural transition for us because we were already working remotely. And then partly because of research projects and also the Linux foundation open source project. We already had a virtual team that we had been collaborating with for years and we kind of knew that they were technically super evil but also super hard workers and nobody in that team would mind working weekends and late evenings and the sort of requirements that the startup would require. Once you have that kind of core and those people know people and they work at unis and they grab people out of like PhD programs and whatever, that sort of percolates. So it was never like a super disruptive like oh my God, we were working like 9 to 5 and quitting on Fridays at 3pm and now all of a sudden we're working weekends. What just happened to us? It was just like we happened to have a team that uh, that it was mission driven always and always was like very into technology and as long as they were happy and interested in the sort of technological challenges they'll put in the hours. So it was a bit of a smooth transition.

Speaker C: I'm curious too. We talked about some of your maybe not as spicy takes now, but spicier takes in the past given where you sit and you see so much going on with like agentic workloads. What are maybe like some of your current hot take takes on uh, kind of the state of infra or things that other people aren't thinking about that you and your team are.

Speaker B: Yeah. So there's a few things that. Well some of the things that irk me is like I think everything should run in a virtual machine. Obviously that's not super objective, but it kind of is, especially with CVS and whatever. Like there is a place for containers and isolates as long as people disclaim exactly what the risks are. So that's one thing that kind of irks me. The other one is, is this space that we got into that Hyperscalers had like 4 or 5 or 6 compute offerings. Makes like no sense and it's just like limitations of technology. Like if I'm a cloud engineer, I don't want to have to decide whether I need to run on Lambda or EC2 or Fargate or split my application across all of them. Like I uh, just want there should be. And this is one of the thesis, like there should be a platform that just gives me all of the best things of Lambda in terms of millisecond timescales, but all the, the flexibility of EC2, I can run anything. And I think that coupled with agents where the UI is just a prompt and they can do anything is a very powerful construct going forward. Give me a platform that can run anything and do it quickly and scalably and put a UX on it that intelligently can do anything. Um, and I'm excited about where that future will kind of take us.

Speaker A: Awesome. Well, our canonical last question for our guests is, what's the number one advice you give for others that wants to start a company? Just follow your journey. What has been the number of advice you've been giving folks?

Speaker B: Yeah, so one disclaimer. Don't do it for the money. Make sure that you're passionate about what it is that you're going to be building because that's going to keep you going for much longer. And through all the trouble, make sure you have a solid team that is aligned with that and that are very happy to put in crazy hours if that's what the work demands. Because you're all just having a good time and fun and you're mission driven. That will be my sort of key thing. And also, obviously, if you have a partner or whatever, make sure that they're on board because they're going to be part of the journey as well.

Speaker C: Awesome. Um, well, thank you so much for joining us, Felipe. This was such an awesome conversation.

Speaker B: Thanks so much for having me. It's been fun.