 Hi everybody, my name is Felipe Wisi. I'm here to talk to you about Unicraft and how to make Unicernals mainstream. As you know, the public cloud is a great success. It has great scalability. It's really easy to use and has a whole lot of services. But it also has downsides. It's bloated, it's expensive, and it's certainly not eco-friendly. And there's been lots of reports stating that the cost of the cloud has become one of the main priorities for many, many companies now. So obviously this situation is good for the main cloud providers. And potentially also one could argue for the hardware manufacturers, but not so good for anybody else. So the problem with the bloat has two parts. The first one is when you look at your application and the virtual machine it runs in, there's your business logic, could be a database, could be a web server. Under that there are system services, libraries, and of course the operating system. And there's lots of part within these that you don't need to run that application, but you still pay for. The second part of the problem has to do with time when your service or virtual machine starts, it's at first idle until the first client request arrives. Then it does useful work, but then it goes idle again. And every time it's idle, you're still paying for services that are not really doing any useful work. And that's costing money too. So basically what's going on is that you'd like to run, you're running basically a full cafe when all you need to be doing is running an Espresso. And basically what we would like to do is specialize for the needs of particular applications running on cloud services. So if we're talking specialization and virtual machines, this points to Unicernals, which are essentially specialized virtual machines. So in a nutshell, if imagine you wanna run a web server such as Nginx, you're gonna have a number of third-party libraries in your virtual machine image. You're gonna have softer services. You're gonna have the OS kernel, perhaps from Linux. And you have lots of little blocks that you don't really need. You only need the sort of colored ones that I'm showing here for the web server to run. And what Unicernals tries to do is graph just those and build it into a very specialized virtual machine that is purpose-built to run just that web server. The problem is that turning the left-hand side picture into the Unicernal in the past has required lots of development time. So in Unicraft, we're trying to fix that. We have a core build system and a principled architecture where everything is modular. Everything is a library so that we can easily plug and play and specialize for particular applications. And then we have a set of well-defined APIs so that we can actually plug and play things. So if we start at the top and we have the application, we have a libc layer with a libc called new live. And we've also recently started adding muscle support. It should be ready soon. Under that, we have a POSIX compatibility layer. I'll talk more about this later, but this is so that applications can run unmodified on Unicraft. And below all of that are the different subsystems with well-defined APIs shown as black boxes. And this is what lets us plug and play different memory allocators, file systems, network stacks, and so forth. Under that is the platform layer where we add support for different hypervisors, KVM, Zen, and so forth. And then of course, CPU architecture support. So just to show you a few numbers, this is a Unicraft Unicernal running Nginx on an EC2 instance. And basically when we open the URL, the instance boots, it starts Nginx and it serves this webpage that has some basic stats. And here in this example, you can see that Unicraft booted in eight milliseconds. It took one more millisecond for Nginx to start up. The whole image is consuming just over four megabytes and on disk the image was under two megabytes. And this is also showing a comparison against Nginx running on Linux with the green number showing how much more efficient Unicraft is. So this just shows the potential. And then the question is, why aren't Unicernals more widely deployed then? So we think there's multiple barriers to deployment that have hindered Unicernals from being mainstream. The first one ironically has to do with performance because if you think Unicernals are specialized VMs, why wouldn't they just run fast? And it turns out that many projects have small but still monolithic OS primitives. So it wasn't always easy to specialize things. There was lots of underperforming code and optimized network stacks and so forth. And many of the projects didn't really target performance. They were using languages such as airline or oral camel and the purpose of those projects was never to go fast. In contrast, Unicraft's target is to have better good performance from the beginning. So this is a measurement of Nginx running measuring requests per second on KVM Unicraft. But also we compared against other Unicernals projects and Linux as well. And you can see where we come up on top. This is about 300,000 requests per second on a single CPU core. We also do measurements to do with memory consumption once again against other Unicernals projects and Linux. And you can see Unicraft on the left is able to run databases and web servers in as little as a few megabytes. Because Unicraft doesn't have a user space, kernel space divide, latency is pretty good. And this is a comparison against Linux. And finally a graph about boot times you saw in that sort of demo slide that Unicraft was booting in eight, nine milliseconds. Some of the time is consumed obviously by the VMM. So Unicraft supports different VMMs, Kimu, Solar 5, and more recently Amazon Firecracker. And for instance, if you use Firecracker then you can boot a hello world Unicraft image in as little as three milliseconds. So pretty quick. And then finally image sizes, Unicraft image sizes are pretty small. For real world applications, you can expect one to two megs. So the second barrier to deployment has to do with application and platform support. In the past, there's been a lot of Unicernel projects that were specific to a single application or a single language. So their applicability was limited. Many of them require porting. So you had to actually take an application and modify it by hand so that it would run on the Unicernel OS. So that wasn't really scalable. And for those that did support some level of POSIX, meaning they tried to look or offer the Linux API, there was insufficient Cisco support. So it was only partly supported. Unicraft already supports a rich set of applications and programming languages. But we also support what's called binary compatibility mode in which we can take an unmodified elf, built for instance under an Linux host. And we have a special Unicraft library called floader, which does what its name suggests. It just loads that elf. And whenever we get a Cisco, we trap that and we redirect it to another Unicraft library called the Cisco shim layer. And this layer then takes care of redirecting that Cisco call to the Unicraft library that actually implements the Cisco. And in this way, you can actually run a binary that has been totally unmodified. And this means that you don't need to port applications in order to run them on Unicraft. The second approach to achieving this is what we call from source or with muscle, which is work in progress. In this case, we take the sources of the application and we build it with its native build system against muscle. And then we take the resulting object files and add them to the Unicraft build. This works because Unicraft has a ported version of muscle, which then redirects again any Cisco to the shim layer. And then that goes on to executing them by the different Unicraft libraries actually implementing them. The advantage here being that the Cisco's actually turn into just simple function calls, so the performance is better. In terms of platform support, Unicraft started several years ago as a simple x86 on Zen project with a dummy libc called no libc. Also several years ago, we started out in support for KBM and NewLib. And then more recently, there's been a lot of effort towards supporting ARM64, which is there now. And as I mentioned, work in progress is muscle, which should be coming in the next month or so. And then from the open source community, there's people working on supporting Hyper-V and VMware and more recently the RISC-5 architecture. So here are just a few screenshots of Unicraft running on Hyper-V and VMware on RISC-5. And finally, you can also run Unicraft Bear Metal on ARM64. In this case, this is a screenshot of it running on their Raspberry Pi A3. Okay, the third barrier to deployment was framework integration. Many Unicurnal projects, when they came out, there were no obvious standard frameworks, such as Cape Kubernetes today. And even many of them didn't have any toolkits. So building these Unicurnals was a matter of getting dirty with make files and so forth. So it was really a difficult, a lot of engineering effort to get started with these. So in Unicraft, we're trying to make this as painless as possible, and we've done this in several steps. First, with Virtual Studio Code, we provide an official plug-in. So here's just a brief video where you can actually get the plug-in and then you can open a Unicraft Bear Metal and you can open a Unicraft project. In this case, we can select a Hello World one. And then you can see there's a special you Unicraft symbol on the bar on the left. And then you can just do standard development and then it'll build and actually run it for you all within VS Code. And underneath, what it's actually doing is running craft. And craft is our toolkit that wraps around how to easily build and run Unicraft Unicurnals. Of course, you could do this by hand using make files, but you don't need to. Craft simplifies this a lot to the point where you can run a single command to build and run your Unicurnal. You just need to choose your architecture and your target application. So craft takes care of any dependencies, but libraries need to be dragged in. For each application, there is a craft YAML file stating dependencies and so forth. These are created by the team, they already exist. And then just a short video of how to use it. If the simplest use case is I just wanna choose an application. In this case, engine X. I just wanna craft to build it, download the sources, build it and then run it on KVM. So this is what the craft up command does. It'll first fetch the sources for Unicraft and for engine X. And then once it's done downloading them, you can see downloading now, it'll start actually doing the build. And then I'll just go ahead and skip to the end of the build. I think yeah, 98% now. And what it's done, what it's gonna do is it's gonna execute it right away on KVM, which is the selected platform we chose. There it is. It's already booted, it's running engine X. And just to make sure it's working, we're gonna curl the IP listed in the outputs to see if we're able to retrieve a hello world page. And there it is. The third part is obviously once you build the Unicurnal, you wanna deploy it. Arguably the de facto standard for doing this is Kubernetes. So we've done an integration with Kubernetes where we created an equivalent for Run C called Run U, which instead of running containers runs Unicraft, Unicurnals. And with that in place, you can use unmodified Kube CTL in the Kubernetes dashboard. As you normally would, it's just underneath your running Unicraft, Unicurnals. And here's a short video showing that the only modification you need to do is to the manifest YAML where you would specify that you'll be using this Run U. And then with that in place, you can just use standard Kube CTL commands. In this case, we're gonna create a Unicraft pod. It's already done. So pretty quick. And then you can list it, of course. And then we'll just show the log to, you can see now that it's running just as before. It's running engine X. We can still get the IP address and curl it. This is just to show that it is actually up and running and working. And then you can go to the standard dashboard. Again, this is wholly unmodified and you can go to the Unicraft pod and get some basic stats for it. You can see the console there too. Okay, and the final piece is, obviously once your Unicurnal is deployed, you wanna see how it's doing, be able to monitor it and so forth. So here we added yet one more library to Unicraft that works as a Prometheus exporter. And then what we do is we create Grafana dashboards out of it. This is an actual Grafana dashboard of a Unicraft kernel showing networking statistics and memory statistics. The final barrier to deployment is to do with debugging. Many projects had no standard tools, no GDP support. So it was really tricky to actually debug him. There was no performance profiling tools and there was poor documentation. In Unicraft, we've been working hard to provide such features. There's a library called UK.debug that you can enable and when enabled, it gives you access to assertions, trace points and a full GDP server. There's a library called UK test for unit testing and UK store allows all the other libraries to store information about their performance. So if you have a memory allocator, you can store and get memory consumption stats there and then you can export them onto Grafana. In addition to that, we created a tool called Uniprof. What this does is it takes stack snapshots periodically and then you can use those to generate flame graphs such as the one I'm showing on here. And the flame graph will very quickly and visually show you where your performance bottleneck is. It'll give you even the function names and then you can go ahead and try to optimize those. And finally, we have done a lot of effort to document Unicraft well. This is available on Unicraft.org slash docs. And then a word on security. If you know anything about Unicurn or even if you don't, you probably have figured out by now that because they're specialized, they have a lot of potential for having good security features because for one thing, they have a small trust in compute base. But if you know about Unicurnals, you've probably seen some reports in the past that have analyzed their security and they've been lacking to some extent. And this is nothing fundamental. It's just that many Unicurnal projects haven't really focused on adding standard security features. In Unicraft, we're trying to change that. So there's lots of security features that are in place or that are on the review or that are planned. I'm not gonna go over all of them, but the target is by the fall of this year that all of these features will be already in and upstream. We did do a test of that EC2 image running Nginx on Unicraft that I mentioned earlier. We pointed one of the security analyzers web-based ones to it and that got pretty good security ratings. So Unicraft is a Linux foundation project. The main website is Unicraft.org. So if you are at all interested, please check it out. We have a very active Discord server. I think we have a very friendly community. So if you have any questions, if you have doubts about whether Unicraft might apply to your project or you don't know how to get started, please drop by. We're usually fairly responsive. Another way to get started is we have a lot of regular hackathons. These are based in cities, but you can always remotely participate. So this is another good way to get started and get some hands-on supervision from some of the maintainers of Unicraft. And then finally, if you wanna read all the greedy-needy details of Unicraft, there's a long white paper that we published last year at Urosys that got the Best Paper Award. So you can read all the details about Unicraft there. And finally, if you wanna get in touch with us, here are your contact information. And if you like the project at all, please star us on GitHub. That really, really helps. And with that, I thank you for your time.