 What kind of application areas they can be used and also why do we need to start with let's actually start with the definition of what So there's a website unikernel.org you can have a lot of information about unikernels But essentially what unikernels are are unikernels are single image operating system So typically you have a virtual machine, you know You have layers and layers on top of it. You have applications that may be doctors and so on what unikernel essentially is Is that it fuses everything into one image? So so there's no distinction between an application a virtual machine or anything in between and I'll have some I have some diagrams to actually include what these layers are and how they're included. Yeah I'm sorry Okay, so let's actually look at the picture today Right, you have an application. It runs an operating system, right operating systems as usually a lot of lines of code I don't know. I think windows is not there but windows is also quite big Linux OS and then you have whole sorts of utilities So this picture Somewhat resembles an iceberg, right? What you care about or what you see is just the tip There's a really big bulky Stuff that is beneath That you actually don't care about and as a result you have a lot of stuff present in your Production system that is running that was not part of your application and often you don't actually need or not all of it right you might need some of it and The problem here is That software is inherently a very complex thing, right? in software you have different different moving parts right you have several processes threads Running and different moving parts what it does is it increases the possibility of failures because there is many millions of combinations of things That would potentially go wrong You also have like millions and millions of lines of code so millions and millions lines of code means your application would take time to boot up to run and Lots of code also means that there are lots of vulnerabilities, right? So every now and then you hear stories about XYZ hack this website, you know all sorts of buffer overflow attacks and so on and The problem is all these attacks that are happening very many of them are happening at the part of the code that you actually don't use and You just have it for the sake of having it and your application suffers because of it It doesn't really get any benefit about So all this complexity is kind of unnecessary, right? And the reason why we have these complexity is because an operating system or a docker even Probably less to for docker, but still the same thing. They are general purpose systems, right? They don't have any particular use case in mind and they don't have any particular user and so on and they don't even have any estimates on the size That use so they are trying to create this one solution that works for everybody And what happens is it kind of works for everybody? But it doesn't work perfectly for anybody because it's like a jack-of-all trade master of none kind of situation right so you have all this complexity and With an operating system, you have a lot of different configuration points, right? You have to configure this you have to configure that you Which often you don't use and if you look at the trends that are happening, you know people are moving towards Microservices and people are moving more towards in an abstract way what we are is we are moving from a monolithic to a world of Microservices where you have more granularity and assembly of smaller systems working together than having one big large ball of mud as I like to call it and these microservices They follow the single responsibility principle Which is rather than you know having a jack-of-all trade system Focus on one thing and do that one thing really really well So the current scenario that we have is kind of an anti pattern in the modern world Most apps are single purpose most microservices one or have one or two end points yet We have to inherit this huge huge big bulk of code that we don't use So the question is is there a way to reduce the complexity can we do that? Turns out There are ways of doing it we'll cover that Another problem that we have is lack of portability that portability probably is not big of a problem when you're running And some sort of managed environment for example Java virtual machine It's it's not a big problem. It is a problem to some extent But if you're using like a low-level note native app like something like a C++ app you're using operating system libraries And as much as you have standards not everybody follows the standard hundred percent So you you end up in a situation where your code is semi-portable right across across different platforms across devices And this is often not not a good scenario because in the modern world But we have is we have a set of a lot of these devices that work together rather than having like one common pattern so so it becomes difficult to Reuse the code and that that's one of the things that we need to worry about can we enhance the portability? so For us to have this problem solved what we need to do is we need to have a solution that somehow You know focuses on the problem at hand and distangles you from the underlying system operating system or whatever platform They're using right you want to focus on your code and not worry as much as possible about the rest of it You also want to do something like if I don't need 50 services I shouldn't have them right my application is a single process application in a microservice right? I need easy scalability, but let's say I don't want too much threading. I don't want a file system I'm not storing anything. It's a stateless application. I have a DD connected right, but I still have a file system so if you have a solution that That only takes all the components of the operating system that you actually need You solve a lot of security problems a lot of portability problems that you otherwise inherit and Finally, you would need something like from a single platform. I should inherit multiple Platforms right so can we have such a practical solution? well, we kind of have it and That solution is called as containers Right, so what is a container a container is essentially a stripped down VM So you don't have inherit the entire VM. You have like a subset of their essentials you build layers and layers of your application and Essentially, you have a Docker and any platform Where containers are supported you can package your application you can run it on your local system Hey, it works then I can take this container as a whole and deploy it on my production environment. It works You have different tools like Kubernetes me so sweet, you know, you're running containers at scale Things fail at scale. So you need a way to handle resiliency all those things good and you can deploy to multiple platform So far so good Except the problem is this is not a perfect solution. It's better than what we have in the VM world, but not a perfect solution. Why? Because containers don't really eliminate the libraries that you don't use they just reduce the amount of it Right so container is basically a mini VM. That's what it is all the services of VM You still have those services in a container not that you don't have it You may not have as much of them or you have less code sure but containers are inherently There are issues with container especially on the network if you have one VM you're running a lot of containers You're likely to have problems. So containers are a Solution it's a step in the right direction But it's not it's not the perfect or it's not the ideal solution That we are looking for obviously there is no such thing as an ideal in the world But we what we want to do is we still want to go as close as possible Where we reduce the amount of inherited code that you have and focus more on the application And that solution comes with unique kernels. So what is a unique kernel, right? Essentially what you have is your whole operating system has certain set of components a unique kernel What it does is it takes your application code and it takes all the components of the operating system that you actually need And ignore the rest that you don't need which is going to be 90% of the case And package them together Sorry about that. I don't know Why is this happening? Okay, good Something happening with the connection Um, okay, I'll just keep talking until yeah So what a unique kernel actually does is takes this library components and uses them together as an application, right? so When you're building your application at build time it takes those components We'll see some example and it only uses the libraries that you actually require And a unique kernel Really is a single process system, right? You don't have a lot of processes let alone thread and so on And what it does is let's say that now I want to port my application in some other platform, right? I still have the uniform interface Where I'm calling the os libraries So my application is ported. Let's say on jvm now I swap it out and I want to put it on a hypervisor running on a gen virtualization server So a unique kernel will target multiple runtime So I would build that application for the second platform that I have It takes the same components that run it takes the equivalent components, right that have the same interface and it packages it It runs on another platform. So think of it something like Let's say you have something like a docker, but it's not one such docker, but there's a docker for Different kind of environment So you can package it in a similar way and generates a different container for each one of the target platforms that you can deploy But you don't hardly have to change your application for it Your application the interface for those components are still the same. So your application remains unchanged. You just have to recompile Your application for your different platform and you're done So this is this is traditional The traditional application stack, right? You you have a kernel space and then you have a user space and your operating system process management network All those things they use the kernel space and then your application library user space One of the performance problems that you have with this is that you have to switch between kernel space and user space rapidly when you're running What unikernel does it it fuses them together. So what you have is there And by the way this networking and that networking is not exactly the same For example, you may not use all components of networking So that component would only have the stuff that your application actually needs And notice that there is no process management because you don't have processes And let's say if you don't use file system, you won't have file system in your application. So it's like on-demand basis So this is how unikernel application stack Would actually Look like Okay, so let's actually look at the evolution of Evolution in the I'm so sorry Can somebody have a look at it What's happening there? Yeah, is this going blank? Okay, now it's working here, but I think there's a loose connection there Okay, sorry, sorry for the interruptions. So I was at evolution See it again goes back My apologies for this but anyway, let's actually look at So you have the hypervisor and then you have big large components of os and then your application And when you look at how How the space is moving what you see is that the app component increases more and more and the os component shrinks So what you have in unikernel is nothing but the next step of evolution beyond containers. That's what unikernel's up But there's a general trend that you should focus more on the stuff that we actually need And less on stuff that is just an overhead that We may not even use so What are the characteristics of Unikernel right what makes unikernel so unique? So I already kind of discussed that Unikernel's are often High performance and the reason why there's high performance Is because there is less code, right? There's less overhead and there is fast There's no switching between user kernel mode. So they actually operate very fast They they're obviously a lot smaller because you don't really have A large overhead of os code in fact There have been cases where unikernel's basically just going kbs to tell somebody, you know kbs That'll be like kidding me But typically for microservices, right? You're only handling one or two endpoints. You don't really need a lot of code for that So unique kernels tend to be very small and what Another characteristic is faster boot types Because you have less code and your code component your hypervisor component. You're sorry, you're operating someone very stingy you don't really need a lot of A lot of time to boot and this actually has a very interesting property and I'll cover that in details in the later slide But you could have something like an on-demand provision. Sorry security often Let me move to slide back Yeah, that actually is a Is a problem Generally because Everything has a root privilege. You don't really have a concept of security Well, I mean you are trusting people who are writing the code to write code you have methods to test code and all those things Right, uh, you have producing logs and so on So you have a mechanism to audit and you have to trust your development system I mean, there is no built-in security. You could potentially add a layer nothing stops you from doing that But there is no inherent security mechanism and it's a little bit of a A little bit of a design philosophy also because the very fundamental Principle of a unique kernel is have what you only need don't have what you don't need So if you need security You could add a layer yourself, but unique kernel will not enforce the security for you Because it wants to give you the freedom of not having it Right, that's that's a kind of a trade-off I mean, it's the same thing as and this is another thing that I've covered later on is like If you have a lot of utilities of your os that you actually need Then unique kernel is not the best way because you don't have that equivalent in a unique kernel, right? the very the very premise of unique kernel is Deleaf just have what you need and put things as you go along Did that answer your question? Yeah, sure okay, so I was talking about the application of faster boot time Um, when you have microservices, you know, scale up you actually can scale up on demand If you have loaded, you know, you have an auto-balance that scales up because Provisioning a unique kernel and booting it to your fast You literally can do it on demand. There's actually a slide. There's a project about a jitsu I'll have the details in that slide, which is what it does. It just Every time you get a request it provisions a new unique kernel as your load expands just on demand And it works because it's just few milliseconds. You won't even notice it Okay So in the embedded system world What you have is, you know, when I was a kid I used to play with not so much of a kid, but in graduate school I used to play with those microprocessor kits, right? You have the 8088 assembly language and you have a development environment on a DOS PC You write that code. You have an emulator that tests it everything And finally when you deploy it in production environment, which is a microprocessor kit in this case Like an embedded environment, right? It produces that binary That you load it on your microprocessor And that's a single image binary So in a way Unique kernel applies the same philosophy to the cloud That when you develop it you have emulators you have testing stack and everything and you test everything's okay And when you talk about deploying it just uses everything is one binary image and just deploys it on your hypervisor And the problem With that approach, which is even an approach with an embedded System is you have no visibility of what is happening in your actual production environment So during your development testing you have all the facing everything you're using emulation So when you actually put it on your device, that's the end So that's kind of a drawback and how you actually usually they do it in embedded systems Then you have to use the same approaches during the development. You could have logging, right? So you take that issue And you replicate that issue in your debug environment and figure out what's happening Some people consider it as a drawback to unikernel. I personally don't think It as a drawback because I've never come across someone who does live debugging in production What you're really doing is you're replicating that in a debug environment Nothing stops you from replicating that in the debug environment anyway, right? So for someone and I don't know of anyone like that who does Live debugging in production that would be an issue, but not for most of us Use case scenario, okay So microservices is like really popular these days every talk on software architecture talks about microservices And unikernels are quite a good platform quite a good way to approach to implement microservices because they are, you know, small independent single Responsibility principle and they have no good time. I already covered that right that means rapid scaling Because you need that elasticity when you operate at scale Another Potential application is immutable infrastructure. So you reduce your dependency on external components How just take everything and prepare it as one image to statically link the data So these are different use case scenarios. These are just typical use case scenarios, right? This is obviously a very many of them So let's actually move on to the development of it. So how This is how a development stack would look like Okay, so during a development, you have your standard operating system and you have a development runtime, right? Typically how it works and embedded right? You have an emulator think of it as an emulator So your application compiles, you don't actually need the kernel routines because your standard operating systems provide you with that During the development phase Then once I have the development done I move to the testing so testing would have all that Testing still will take all those kernels and file system because you want to know How your application will behave in the production environments will take into effect, but you're still learning under the standard operating system and finally Once your testing is done. You actually Move to the production. So production takes everything and Then puts it on the hypervisor and this is where you lose all the All the visibility of your system Another thing I should actually caution about in kernel is That because there is no difference between an operating system And an application. Let's say you allocate 4gb of RAM To an image right on your system. It will show that you have 4gb finish You're consuming all 4gb even if you don't actually use it Whereas I think in dockers you actually have the ability to take some gb from one container and put it another you would not have that Operate you would not have that Facility in unique kernels because the fundamental fact is a unique kernel does not differentiate between what is an operating system And what is an application they both the same And what tends to often happen Is that you don't want your system to crash during production from running out of memory? So as a result, you know, you tend to overestimate the amount of because you want to play it safe you tend to overestimate the amount of memory that you actually need And provision it accordingly All right, so let's actually go to the benefits of using Well first and foremost You have, you know smaller image. So you have smaller image means you have A either you can use a cheaper VM or you can have high multi-tenancy Right, so you can have several applications packed in one VM You have reduced memory fin and you have reduced computational burden So you don't actually need that much of computation power To power a unique kernel application as much as you would need in a you know a traditional Let's say VM Docker based application Um another advantage boot times, you know, you're talking about really second so Reduced Okay, sorry text is gone faster boot times, right? You have really fast boot times Because you're talking about new seconds. You have less amount of code Better security You have less amount of code means you are giving basically an attacker less attack surface Because an attacker would exploit known vulnerabilities of os and chances are you actually don't use those components in the first place So attacker can do anything you also Don't have a command line shell So you can't have like a root privilege and you know root run root commands. You just don't have it So reduced attack surface essentially gives you a lot better security properties in the kernel Okay, why not? So far so good. We are talking about all the benefits. Obviously, this is not a perfect solution and There are drawbacks to start with You you're working on the premise that I don't use a lot of components Of operating I don't I don't need all the components of operating system. But what if you need them? Right. So this is unicernel is like an on-demand, right? I don't need file system I don't have file system. But what if you need it? There are times where you need a lot of utility and obviously those are the times you don't want Because they they would not have all those you have to implement it yourself. It's too much of a burden So there's a lot of software for Linux that is not present in Unicernel and one of the drawbacks generally with unicernel is that it's relatively a new technology, right? And with any new technology, there is a There's a lack of tooling. There's a lack of knowledge. This is just not good enough ecosystem. Hopefully Hopefully this is something that we would fix As time passes by but That's the state of of is right now um If unicorns are still gaining popularity, I think with with with the switch to microservices I would say that adoption of unicernel is going to be much more than As opposed to now, but it's still, you know, it's it's a while before we see unicernel entering a mainstream technology Okay, so we have a lot of implementation. I just have some of them, right? But if you go to this website, you have a lot of them um one of the things with unicernel is because the operating system and Your application is fused together. You have a limit on a certain kind of programming language is good You don't really have a general purpose system that a VM has So for example, Mirage OS, you have to have your application with a language called OCaml for those of you who's not familiar It's a functional programming language From the ml ml family that was in 1975. They had this language called ml use for natural language processing theorem So on so Mirage OS is there in a click OS, you know, it boots on the 30 millisecond very tiny you have um Haskell's VM hl and this is actually made by a famous company called Cal it's actually a French company. They write it as gal was the ground is that gal was this requires you to have Haskell um, you also have some kind of Unicernels that basically emulate something like a Tomcat server, right? So any application that is running on Tomcat server you could potentially Have it in unicernels and you put it on this Uh, I forgot the name. I think it's osv osv is an osv. Yeah, this one this actually I think emulates the Tomcat server Okay, so one of the popular virtualization server for unicernels is then virtualization server and What Zen virtualization server is it's a micro kernel design, right? So it doesn't have that monolithic It uses para virtualization. What is para virtualization? Let's say that you're you're running a network, right? Your data comes in your data is unpacked and then your application because the application does not know whether Let's say you're running on a post read, right? And you have several VMs running on a hypervisor Your application does not actually know Whether you're running on a hypervisor or native VM, right? It's transferred into that So you have a data coming from the network You actually unpack the data and then you have to repack the data and then send it to the application Which will unpack it again. So para virtualization is sort of Uh, essentially a modified image where it makes a certain assumption And it's aware of the fact that I'm actually running in a hypervisor or in a virtual environment and not in native So it has it expects a uniform interface And in that interface it actually Can do a lot. It doesn't have to do a lot of unnecessary work that a traditional VM on a hypervisor would have to do So what it gives you is the benefit of having high performance then is a very high And it also has a live migration. What is the live migration the term live migration actually is a Little bit misleading. It's the right term. I think would be semi live migration. But What live migration is that you can move your image While it's being run from one physical post to another physical post With almost no interruption and I'm using the word almost because there is I mean any impression. That's why I'm calling the Semi live migration But you could do that whereas you can't do something on like that on a docker idea to stop We deploy in a physical post and that's important Let's say in an application areas where you have to move an application It's running from one data center to another center because maybe Maybe your users come from another part of the world Let's say I have an application running in a us data center and suddenly I have a surge of application coming A surge of requests coming from china and I think it's actually better lower latency for me to move this application from my us data center to China's data center Can do that without interruption. That's what then allows you to do a lot of a unicolonial projects actually target the zen Zen virtualization server including mirage os and talking about mirage here. Let's actually introduce mirage os So mirage os mirage tool basically builds these unicolonial for various backgrounds now that you see here I don't know if it's visible. I think it is. Yeah, so you have different back ends x86 hardware the browser And you know boogajava which can run on google app engine And what it does is that it it has these components for all of these back So it takes your application and you have to write your application in okambo to be used for morad os And combined with you can retarget all the different kind of Platforms that mirage supports I think the mirage os Um has some additional This is this is up till version 3 version 3 supports some additional Platforms that I have not included here Okay, so we talked about on demand application Well, there's a project called jitsu. That's the source And what it does is is just in time summoning of unicolonial. So As I have a request I can just boot up a unicolonial process that request and you know, there are all sorts of different configuration I can keep it alive But if I see that the request load is doing and I don't really need that many instances of the kernel I can shut them down You could do the same thing in a traditional environment The problem is that it takes more time it takes few seconds for you to boot up and shut down Whereas in unicolonial because that boot up and shut down process is really really fast you can do it Quite nicely like you can do it at a rapid pace of scaling downscaling and upscaling So dns server would start the unicolonial on demand. It's it's actually being tested on mirage os Mirage os folks. They actually have this jitsu project and drum cup unicolonials anyway So I have some resources For mirage os we have this for unicolonial. We showed this website actually wiki page is is quite Described gini kernel quite well There are some research papers. There are some articles and we do have a book from orally about internals so That's a good reference Coming towards the end the conclusion. So unicolonial is a promising new technology. It's It's actually the next step of evolution, but Again, right now it's kind of immature. I would see the adoption going more as we move more toward the microservices world but relatively now it's it's It's in its infancy. It's particularly relevant for cloud and microservices that as I mentioned They are secure images support very high multi-tenancy Very fast boot times on the one provisioning. You have a lot of open source projects They are some commercial projects also, but they support a large number of different platforms and runtimes But yeah, it's it's still in its infancy and you know, there's an ecosystem around it is relatively immature I'm up for push-ups I think microservices would have a lot of use cases I do not know of right now. I'm not aware of any big case study or any particular commercial application that I can point out Because like I said, it's a relatively new There's open stop running, but I would say that microservices would be one potential application area that I could completely see And what makes unique kernels really good for microservices that two particular things that stand out one Actually three I would say one they are small images, which means high level of multi-tenancy So that's more cost effective for you right in one year. You can run many instance be security less attack surface and three Fast scale Because you have low boost and you can create more instances very fast So microservice is actually something like a really good application area for unique services microservices. Obviously have gained a lot of traction Many organizations have adopted it some are still in process. I had a friend in microsoft He actually called me last year the microsoft has now started adopting microservice. Yeah So those would be the particularly niche areas for unique and unlike any application I'd say that it it picks up when you have a certain niche areas where there is a dying need for it And I see the potential how far would unique kernels go? Nobody Any other question That's why you need the whole Let's say Unicernal one I would still have different using different Us Yeah, so I agree with you monolithic is obviously an anti-pattern for Unicernal I think in terms of adoption and this is this is not related to unique kernels you The graph is not a linear graph that you go over time right you have some early adopters and they experimented and you know Everybody says things and then you have a little bit of disappointment because people start thinking this is the perfect technology unfortunately, there's no such thing as a perfect technology and finally you find like one or two niche areas where You know, suddenly it becomes popular. Hey, this is the kind of problem solved and then everybody starts doing this So the graph would look you know Initially the growth is slow and then there is an infliction point and then it picks up Unicernals have obviously not reached that infliction point and hopefully to do but obviously there's no such thing as a guarantee in that aspect So, yes, we are in the infancy and also For for a lot of high adoption you need a mature tooling tooling is often very important. I mean, I've had people using antique system just because everybody uses java. Sorry in my personal opinion, they suck but There's no doubt about it, right? So the ecosystem actually Matters and it becomes a cash 22 situation right people want to adopt because there's a good ecosystem But there'll be a good ecosystem because there has to be good. Yeah So once that cycle hits a mature point, you would see the growth We are not there yet in terms of Any other question during the build time During the build time you can actually because you import the library See think of think of your traditional operating system, right? You're importing certain headers So imagine that let's let me talk a very simple c++ stuff You're you're importing stdio or some sort of header, right? Now if you have a smart compiler That says okay, you imported stio But I know from your port that you actually use the 10 functions out of the 50 functions, right? I would create an stdio for you that only has those 10 functions And obviously if those 10 functions call something else then I would have those dependent functions But I would not have everything Right So a mirage compiler or any unicorn compiler is smart enough that it knows When you declare that these are the dependency actually you So it it has this entire operating system It's library component and then just pulls those components as and when needed rather than just pulling everything become and that happens during the compile So when your image is built it only has Any other questions? Thank you