 So Unicraft that's a new project Which is covered on the well, let's say it's an incubator open source project part of the Zen Project and also covered by the Linux foundation and it's all about unicorns in this project so Let's see if I get you guys convinced because my aim is to get as many contributors To this project and get this thing growing because it's a Super nice topic actually so What are Unicorns so what are there for and What are they actually I don't know if anybody you heard about that already So but I think I'm pretty sure that you heard about this container craze Right, everybody is running their services in a container You hear sentence like Google runs all the services in container then you have suddenly things like Amazon Lambda Google container engine and Azure container service and so forth popping up But why are containers to pop you up currently? The thing is that if you if you deploy your service with a container you get Some some benefits for instance very fast instantiation times of your service like in the order of hundreds of milliseconds You have a really small memory footprint for each of your Container for instance a docker container support which basically depends more on the application that you have in that box It enables you a higher density like you can run hundreds of thousands of container instance on a single host and if you take this and look at VMs VMs look just you know Heavyweight fat inflexible like thousand thousand instances of VMs on a single host. I Don't believe that But at the same time when we talk about container we need to also be careful About some certain security risks I'm not saying that they're there, but it's a bit more risky in terms of development The reason is actually coming from that all the containers they they share a same kernel and also that it's API and the current API are system calls and Disisolation is implemented by Putting in checks and and so forth into each of the system called and you know If you see on IO control or get other system calls It can get quite complex for each of the system call And also if you recheck the latest Linux releases the system for numbers is Incredibly increasing compared to hypercalls numbers on hypervisor so Of course, I don't need to tell you if one container uses a system called which is not really Protected securely And you break out your whole system is in danger so usually the trade-off that you have today is kind of a Picking of poison choice, right? So either you go for containers You know that they're lightweight and you have this super fast popping up services But kind of maybe not well Night Because you know the isolation might be ify When you go to hypervisors, of course, they promise you strong isolation because they use CPU features for doing that But they're pretty heavyweight But now I Hope I can break the move with you that VMs are actually heavyweight Because we have this thing like unicorns now So what is it a unicorn so on the left side you see a traditional VM, right? So you run your service within your virtual machine It has a general purpose operating system underneath and some some some kernel features So what is different when we run our service in a unicorn? so first of all We want it also in the same virtual machine isolation protection boundary, but instead of using the general purpose Colonel underneath we built a purpose-built thin kernel layer under the application that has only the features that the application requires and Then you can do even assumptions like since you run anyway one application In one virtual machine domain you could even wake up the isolation between common user space and can start even optimizing the interface between application in the kernel because That kernel layer is anyway purpose-built for that application So benefits you get even further from the specializations that where you say, okay, I have now optimized Functions to enter my kernel on my drive. So in numbers In this graph you see on the on the horizontal axis a number of concurrent instances deployed in the system and on the on the Vertical axis the the deployment time and I start here with comparing the numbers how long it takes to to bring up a process and We are roughly there in a bike path that we doesn't take longer than 10 milliseconds to pop up Processes process and processes If you use them docker and put that process So I forgot to say that process is doing nothing. It's like just a black box his baseline measure here So if you put that in a docker That boot time increases and we end up roughly in the bike path of 150 milliseconds to 550 milliseconds, which is pretty good because it's still At least it promise you to give you more protection than just running the the process is planned on your system If you compare that with Devian boots so meaning as a representative of a traditional VM That number goes up from two to six seconds in the best case And when you have 1,000 concurrently running on that system going even up to 82 seconds So here I agree if I see that graph. Yeah traditional VMs have really heavy weight for you know these agile services But if you take now a unicorn and so this one is a is is is called mini s This is part of the design project was more for educational purposes But if you just take that build it and also do a no-op in there We are roughly already in the same park than containers meaning it shows That Unicorns are similar as passes as containers so now you may be heard of a Recent publication that we did that we call like the end. So we are actually tackling into that system on the Zen system to figure out actually where it's all my time spent when I pop so many VMs and We figured that most time is lost in the VM management code So we replaced that put put in put complete own management to set on top and ended up Creating VMs even if you go out now up to 8,000 concurrent instances Between 5 or 2 and 8 or 6 milliseconds. It's the same Unicorn as before and as a comparison Docker we run out on the same machine which has actually 128 gigabytes of DDR3 memory We run out at 3,000 Docker instances So this shows that there's an immense potential in Unicorns Which is not used yet So the games of Unicorns when you run them in a in a virtualized environment are Fast instantiation so we know that from Docker, but we found even it can go even to tens of milliseconds down We have also a low memory footprint The we can achieve really high density as I just saw on the graph and now the more pluses come which is due to the specialization that we can do let's say Optimize our kernel layers towards the application We can achieve even higher performance and we had some Unicorns built in the past one for what was a static HTTP server that was able to cope almost it 40 gigabits of throughput and Having said that it had only a single gas CPU assigned for this and also the attack surface is reduced because You have less components in the Unicorn Right and your Unicorn has also the kernel layers with it so you don't have kind of this shared kernel approach and The other extra is the strong isolation that your virtual machine box gives you so now you may ask me cool Where would I like to use it and the thing is Depending on these technology advantages that the use cases are quite wide range of it kind of you pick pick on one of the different areas that you you gain with Unicorns So to give you some examples fast boot times and migration times You would like to have it for reactive VNF So meaning you have a DDoS attack in your telecom operator network and you pop up on the fly a blocking firewall in front of that access and Your DDoS is is is gone lambda functions As well you put them up for running a single single function and then kill them afterwards So you don't want to have some really heavy weight that takes forever to come up The other the other differentiator is the resource efficiency which comes from this minimal software stack There you can imagine also for telcos. So you notice I'm having kind of a bit telco background You could imagine you could run for each customer that you serve your internet connection a VNF because you can run Thousands of them on a single post but also resource efficiency gets quite important when you go into embedded areas like IOT or You know mobile edge computing where you don't have that many resources that you actually can waste High performance of course a super hot topic for network function virtualization, but also mobile edge computing Including other stuffs too and then mission critical. So as Last said, this is quite difficult to to get your code certified Of course, we don't have this development model yet in the Unicron But at least we can promise that code base is small which makes already all these You know the price for verification much cheaper Then we have the strong isolation between our system because of the hypervisor and this is really interesting for You saw it for automotive applications or any other industrial-grade virtualization solutions So now you say probably cool, but why Don't I have a unicorn right? Why is it not there? And the thing is the devil is in the detail Such optimization that you saw of So these these optimized unicorns are for now manner of built and it takes usually months or even longer to get it really working that way and The the biggest issue is actually that it's kind of a throw away You go go through a process a couple of times again for each of the different application because you want to Specialize your kernel layers differently Depending on the application that you want to put in the unicorn. So in practice this looks like when you take For instance engine X and you want to have a unicorn you probably start to run it on a train of purpose So as and see what's what's there? And you will notice that you know many libraries Many kernel features even are completely unused and Not necessary to run your service so what you then would start is like Building a system just picking these necessary pieces, which is already lots of work Especially when you when I say you take some pieces of the kernel out To get to get your unicorn But then on the second iteration you probably will start Replacing let's say some libraries with different implementation because you figured out that that application Performs much better with that or maybe you have more resource constrained KPI so you start tweaking and tuning the whole system until you reach what you want to want to have right and This Unicraft project is Actually all about these steps. How can we simplify that? How can we reduce the amount of work that you have to do in order to get your engine X in a unicorn box? So when we started with this project, we had we had the following motivation behind first of all This Unicorn build framework Should support everyone's use case this means that some people are really concerned about what? What does your network drivers do what? In sense, what does your CPU? Kind of kind of they really picky in which way network packets are scheduled to CPUs to process it for NFV and others Take care more about memory Allocators to get better performance for different services. So the framework should support all of that it should for sure simplify the building and optimization as I promised and We want to build this unicorn framework also To get rid of this throwaway attitude meaning that Hopefully since you heard this now More unicorn projects are starting to build their unicorn based on Unicraft So that all the efforts they did to get their application run is Collected in a single base and maybe beneficial to for other people and the design approach that we have chosen is Everything is a library and when I say everything is a library. I mean even decomposed OS functionality like schedulers memory allocators and drivers. They are all libraries and Unicraft for now consists of two components. You have a library pool, which I hope we can Together increase it and a build tool that simplifies your building and optimizing your So when I talk now of about Operating system decomposition What's the issue here? The thing is that let's say let's take Linux or BSD the system are usually monolithic and really tied together What we actually want is like a library For each of these components like a library just for supporting file systems because you could imagine you have unicorns They don't need file systems at all or you want to have Schedules as a separate library or you know memory allocators and so forth. So so the challenge is here to take some OSes and pick some pieces out and redevelop it in a way so that it gets a more self-contained Box that you can plug in and out for your unicorn build So let's have a look to the library pool that I said as one component of Unicraft So we distinguish currently between three types of libraries First is the main library pool which includes OS functionalities file systems schedulers Network stacks and the goal is even you know even to provide new alternative Implementations like you have on Linux with tons of different file system implementations You pick the one that fits most for use case We want to have this for schedulers for network stacks Let's say you have lightweight IP or you have the the BSD network set ported and depending on the application One or the other is a better fit for you Then we have the platform libraries. These are actually the libraries that implement the Really the thinnest layer down to your hypervisor We have support and for now for Zen we can run cadm and There is there's one target for Linux user space for debugging purposes And then there are some architecture lips that some CPU architect architectures may require for instance on arm 32 bit we had to provide 46 bits Arithmetic operations and software for modulo and divisions. So in the ideal case now you pick you select your app Then you select and config the lips with the build tool which are showing the next slide and Then the rest should happen magic and you get your audio unicorn images that are optimized for these various platforms So for instance would have one unique Unicorn image for KVM. You would have a different image for Zen because then needs different drivers The interface is different, but you can you know, you specialize it for them and the other for KVM and so forth So the build tool is For now a k-config based so you know it from from the next time you played around with that and has some make-file magic Actually, I learned a lot about make-file by doing this So you have the same principle as when you build a linear you have to make menu config Then you select your your options live is you want to have for your application you select your target platforms where you want to have an image built for it and It's I save your conflict and I make and then that's it so to make this a bit more clear also with a bit more a Closer example, let's say we would build a Python unicorn We would say we take the Python interpreter and take that as an as an application You feed that to the to the Unicraft system and then we select like a network stack to get socket operations we would select a fitting memory allocator console drive and so forth and Unicraft builds as the unicorn with another example, maybe some of you had already about clickers It is a small VNF unicorn where you actually use the click router software and you do the same thing right you select the components you need and Unicraft builds it for you, so the unique any question so the the Unicraft Open source release we started with version number 0.2 with the code name Titan So let me briefly introduce what we have now The the library pool Consists for now really of basic functionality to get a thing You know running and up and for people getting their hands dirty as quick as possible So it's not full flash now, so I expect much more libraries in the future But for instance, we have a memory allocator ported for Minus, which is uses the binary body allocator principle We have libraries for debugging. We have a Scheduler interface There's there soon Besides the cooperative scheduler. There's a library coming up for preemptive scheduling Platforms we support is Zen KVM and Linux for now and Most of them run on both on x86 and also smaller arm boards with on the seven CPUs So when you build now with Unicraft something, let's say a library you you will you will Bind it to this core Unicraft repository which has internal libraries The make file system and the k-config system so in each library What you need to do besides having the source code you need to provide a conflict at UK Which is actually k-config syntax to provide your configuration interface and a make file UK which gets sucked in by the make file system to do this built for the library You can do at the same time Provide the library also externally by using external repo The structure is exactly the same as internal libraries and the system it allows you that an external library can replace an internal library because it's just a menu item where you then select a different one and your application in This bill system is also just a library. So the same thing you have make file of UK and a conflict UK The only difference is you have an entry make file here, which looks like when you develop a Linux kernel module off tree Looks like like the same thing it just you know calls the make file system of Unicraft handing over all the parts of where your sources are and then that system sucks everything in and builds you the bigger menu and Automates the the compilation To give you a baseline example what we achieved with the first build we could do with that tool This is a Zen Paravirtualized guest That's actually just boots and comes down and shuts down afterwards and print some debug message messages that it was up The VM image or the VM kernel image actually because we don't need disk files is nothing there It's just 32.7 kilobytes of size In this pie chart you roughly see how the space is Distributed among the libraries that we had to select most of the thing go to the platform library that implement the interface to the Zen hypervisor and We can boot and print it and since it's so minimalistic We were also trying out how much what's the minimum amount of RAM we need to assign to get it actually up and Even we had to change the tool stack to in order to get that Because it's limited to four megabytes We could design with we could put it with 208 kilobytes of RAM So now I want you I hope you are all convinced now So please join us says so the project as I said in the beginning was Accepted as an incubator project under the Zen community, which is by the way a really great open community and really supportive and We need you now for our ambitious goals because that library pool needs to increase in order to make that really useful for many people So if you're interested, please have a look to our Zen pages and For the Unicraft projects or drop us an email on our mailing list Or even join our ISC channel So the core Unicraft teams should be present there all the time to answer some questions and If you kind of in the mood like yeah, I would I would like but I have no idea what I could do here We have a huge list of all the topics even written down in the Zen wiki So just get in touch with us. We can find something That might interest you as well Okay, then let's show you a small demo of this hello world So that I Prove that is real and not a lie and Then we can go for for a question round. Well, this is now my development system As you see on the bottom of the screen, this is like top But this is the Zen version of top So it lists you the virtual machine that they're running in the system and on the bottom you have you have you have my shop so let's Start with make menu conflict because that's To show you how the the menu looks like so you could you select first your architecture you want to build your application And you can choose between x86 and arm Since my my VMs x86 keep that one Platform you select what you want to have so here. It's already enabled a Zen image Let's say I also want to build an image that's optimized for KVM Or we take also one that runs in Linux user space because of the wide debugging tools that we can use them then this is The library pool for now Here we can select unselect or configure even the libraries There are also some hard dependencies selected by the application already and also by the platform So for instance a minimalistic lip see is required by the platform So you can't unselect it But if you have a full-blown lip see you can replace that no Whatever you have the g lip see new lip see you name Yeah, they're all configurable as you see in UK debug we can enable a certain debug Okay, then you save your configuration By make and you see it builds all the library libraries separately and then links Define the according libraries together This looks like this So this is our KVM image 40 kilobytes of size We have a compressed version which is 8 kilobytes of size We have one for Linux user space and we have here one for Xen It's slightly bigger now because it Adds a memory allocator as well. So this is a bit more for then on the slide that I showed you before To prove you that it runs First show you that it runs on Linux user space here. Here we go And now I will create So I have some scripts around the tool stack to Simplify that with it. It's a sign You know four megabytes of memory. Let's start working and here we go, and it's already dead already So meaning it was so quickly up and down that we didn't see it down there So what I have added to this example is a busy loop So that I can prove that it's actually the application options Enable this So now the unicorn is not going down anymore. It's now wasting the CPU by just busy looping, but at least you see That we run it again Yeah, and Now you see so the Zen tools are not, you know Not not prepared for you know VMs that come and go in the seconds. So now Any questions? I put you the sources again for you know, but you have time to write the down write them down It's also possible to meet me at the Zen booth I can show you also another demo with another unicorn and yeah, we can have a chat. So yeah, please Yes, I know what you mean. And so then what that image that we have for now is build also Yeah, the question was if you use KVM tool to run that unicorn instead of chemo for KVM The platform library that we have for now supports only the chemo version and Can can be booted with the with the direct kernel group Let's say Using KVM tool makes definitely sense. I think it will improve the boot times for KVM as well They I know there is a project Driven by by the real mean Mirage OS unicorn guys and IBM guys, which is called you KVM so they they even gave one go one step further and Provide a different abstract hypervisor interface, but in principle you can all integrate that into unicorn What unicorn is concerned about is only that the library needs to be there to support that case Yes, yes, I know you could even you know share the host tcpipistake and give Sockets Any other question so so the question So the question is about how to include when you when you build now something like a python language interpreter as a unicorn How to include like Python libraries into that whole unicorn system? So for now my answer would be either you kind of Use use an intermediate language of your Python interpreters You know, you don't run the interpreted language in a unique kernel. You would kind of compile it with Python Compiler and get these objects files and build that together as as an image Alternatively, you can also use the Python interpreter add a file system underneath attach a disk image and run your Python code directly interpreted and Load the Python largest from there. That's actually a good question. So microcurrents actually So the question was how is it different from microcurrents the big unicorns so the question My answer is it's it's a different system design unicorns are still monolithic So it's a single current image where you include the features that you need. So you don't You know decompose into several server processes your file system Support and so forth into into other protection domains to keep it included in your in your unicorn So that was a question behind So the question is what are the ambitious goals and where do I want to go so the the target is really that this is kind of Built framework for future unicorn projects Meaning I would like to see UKVM as you mentioned here in the first row Also included as a library there that simplifies you building your application as a unicorn Also, I You know, maybe it changes the way how you do IOT you could imagine This is a neighbor for multi-tenant IOT platforms where you run a hypervisor and resource-constrained device and then You know you to deploy your IOT services as virtual machines and since the resources are scarce a Unicorn would be a fit if you don't want to settle on on containers, for instance so I would Really want to see that project going into several directions kind of, you know multiple use cases like NFV IOT You name it so it should it should be in the starting base to simplify your unicorn project Actually, so the question is about the license that we have chosen for Unicraft. So Unicraft is a BSD three clause license so I hope That's good enough for most of the things you want to do So of course what you couldn't do is now taking something from Linux and put it in there because you might get the license complex but you could still take the BSD network stick and put it as a library and Have something feature-rich as a networking stack in the other questions so the question is about how to You know Select dependencies how that works in this build tool So all this dependency handling is now built into these config.uk files so When you have your engines applications you kind of still need to do a bit of analyzing step to to understand What are the dependencies that I need? And you would you would write them down as library dependencies to the Unicraft system or feature dependencies that you need Let's say you need a socket interface. So the user would need to Provide you a TCP IP stack that comes with a socket interface as an example or you need a VFS so you do define I Need VFS layer. Please give me one and then you select According library to it. So that is all bundled into this config.uk So question is how is this different from Erlang on Zen? I can tell you Erlang on Zen is Minus and the Erlang language on top You maybe heard also of other Unicons like MirageOS which is originally also Minus and you have an OCaml Environment and then you even by develop some divers in OCaml The thing is it's not really different. It's like, you know, you could build these Unicons with this project too. The thing is that when these projects started there wasn't a single place where people contributed to it and This is kind of, you know, the issue that I was mentioning that the Unicolon for now is more or less a throw away thing So you build a Unicolon, go through all these optimization steps and so forth, but it's just for this use case, right? And it's not going back to a single place where other people could get something from it. And also the plan is also to get, let's say, Mirage running with Unicraft platform libraries underneath. Thank you very much