 Okay, so let's get started. And please welcome Michael Bright. Michael Bright from HP. I work for HP in Grenoble France. Can you hear me okay? No? Is that better? Ah. Okay. So I work in Grenoble France in an open-ended fee lab. That's what I do daytime, but otherwise I'm containers, containers, unicanels. So I'll talk to you about what are unicanels, why we need them, and what domains they might be applied to, about the different unicanel implementations, about containers and unicanels. I think that's particularly interesting. I'll give a short demo, very short, and then some conclusions. Ah. Okay. So why this talk? Well, it's a hot topic. As I'm sure a few of you have seen a mention of unicanels this morning. I was expecting to have to wear a Kevlar suit, but I think you're a friendly crowd. Okay. So I'd like to talk about what we can expect to see from unicanels. I think it's the main that's moving quite quickly now, and in particular what I think Docker will be doing in that space and who the different players are. So first of all, don't forget, unicanels have actually existed since the 1990s. So there were exo-cernel and nemesis projects from the 90s, nemesis being from the University of Cambridge in the UK, and they're continuing to do a lot of work in this domain. Back in 2014, so I skipped forward a bit, there was a seminal paper on unicanels published by ACM. And then in 2015, we were already in container mania. I was anyway. And then we started to see articles like this one, seven unical projects to take on Docker in 2015. So I started to wonder what this was all about. And at the end of 2015, at DockerCon Europe, there are a couple of guys from unicanels systems, MargeOS Zenproject, who did a cool hack at the end of DockerCon. And then in January 2016, Docker bought unicernel systems. So everyone wondered what's happening here. Actually, back in early 2016, already there were a bit of reaction to the fact that Docker were buying unicernel systems. People were wondering if this was really feasible. And since then, we've seen other people come back in defense. Okay, the other thing is 2017. I think we'll see some important developments like the third release of MirageOS, which I'll talk about. And I kind of expect some announcements from Docker this year. So what are unicanels? So unicanels or libraryOS, the idea is that you build up an application including essentially the OS elements that you need. And so you build a static binary application that doesn't need an OS to run. It runs either directly on bare metal or much more typically on a hypervisor. Okay, and something quite specific about unicanels. So I've written there single process applications. Actually, that depends. There are probably at least 15, 20 unicanel systems that exist. So they're not all the same base. But in their more pure state, a unicanel application is a single process application. It's single user. It's single address space. So there's no context. There's no concept of kernel and user address spaces. They're very small size because you select only the bits of an operating system that you need. And they're very fast to boot. Hundreds of milliseconds typically. They have a small attack surface because they have a small number of lines of code. I mean to give an idea, Linux kernel itself, not the distribution of the kernel, has about 25 million lines of code. Of course, you only compile a fraction of that when you build because of your configuration options, but still it's enormous. So unicanels use a much smaller base because they pick and choose from the OS itself. And potentially that will lead to greater security or at least source code will be easier to manage. It will be easier for one person to know what is in his application. There's potential for higher performance. For example, because there are no context switches going on within your process. But there's no shell because we're talking about a single process. So you might worry, well, how am I going to debug this thing? Well, you debug in the same way that you would tend to debug an embedded application or an Android phone and so on. You'd have some other machine tethered to your device. So why are they needed? Well, you think for a moment about what OS you're running, probably Linux. And on what hardware? In fact, you're running a generalized operating system on probably diverse hardware. So the Linux kernel or other common operating systems. They're general purpose operating systems which are great for a laptop or a desktop. But they include a lot of backwards compatibility, a lot of features that one particular application isn't going to use. And the principle of the Unica is that you only take the elements that you need. Obviously, you're not going to run it directly on a laptop. You couldn't do anything. But we'll see domains where they are useful. So basically on this continuum going from monolithic applications running on bare-metal hardware to VMs, to containers, and now Unica and OS providers another option. But they're not necessarily a panacea. We see there are problems. So if we look at what domains we might use them in, well, obviously in cloud computing, they're small, immutable entities. They boot quite quickly. And they provide the possibility of having command servers just in time creation of Unicanals. Also in network function virtualization. So the same interest as the cloud. NFE is basically cloud for telcos. But with stricter requirements on response times and so on. And Ericsson Research have published information about a proof of concept they did in the NFE domain. Just an image of that I'll show in a moment. Another area is IoT or embedded, where we can have low resource applications deployed out there in a very distributed fashion. While they might be bare-metal, that's probably not going to be that practical. So these will probably be running on very low footprint hypervisors. And the approach is to then build up the application, rather building on some generic OS that you're trying to strip down. Similarly for high performance computing, because there's potential for much better performance, on the other hand, it is trickier to work with Unicanals. So the short term, it'll be hard to work. This is just, I mentioned the Ericsson case of NFE. This is one scenario that they had worked on, where running on a Zen hypervisor, they have one unicolonial here, which includes the TCPIP stack, and then a series of virtualized network functions, DHCP, NAT and firewall, which do not deal directly with TCPIP. They communicate via this VCHAN. That example was written using Mirage OS, which is all written in OCaml. So I said that there are maybe 15, 20 implementations. There are two main families. So there's the clean slate approach, where typically the whole library OS is written in one functional language. And it's quite a purist approach, but that is really what Unicanals are about. And then there are other legacy approaches, which tend to go for backwards compatibility, positive compatibility. Some of these are capable of running directory static binary. Others will integrate either a GVM or even Node.js. So we're getting away from the minimalist approach with the clean slate systems. I'm not going to go through this list. I would say that almost all the unicolonial implementations I know of are open source. One exception is actually Drawbridge, a Microsoft project, which there's very little information about it. There's certainly some announces about eight, nine years ago and a bit more recently. I expected these actually used in Hyper-V and Windows Server 2016, or at least components of that technology. I just wanted to point out, ClickOS is one from NEC Labs, where they're embedding unicolonial into their networking hardware, into routers and firewalls and so on. That's a very practical application of Unicanals. So I talked very briefly about MirageOS. Unicolonial systems, the company that Docker bought, they are deeply involved in MirageOS. I'm not quite sure between University of Cambridge, Zenproject, MirageOS, Docker, who is paid by whom, who works on what, but they're certainly working on MirageOS. That said, the cool hack that they did at DockerCon, it's interesting to see that they used another unicanal technology. They used Rump Kernel. So there seems to be a lot of collaboration amongst the different unicanal projects. But anyway, MirageOS is written in OCaml, and that means that the unicanal base or the library OS components are themselves written in OCaml, which is a functional language derived from ML. So that leaves possibilities of performing proofs on some parts of the code. So MirageOS provides a tool, Mirage, of course, which allows to build unicanals for different backends. Generally today, the two backends that are used are either Zen or Unix, so it can produce static binaries that can run on a Linux or Mac OS laptop. They do also have a browser back-end that uses conversion to JavaScript, but I don't know of any practical use of that one. MirageOS 3, we're coming out this year. They're preparing a first beta of that, and that is integrating an IBM project called Solo 5. Solo 5 is adding a unicanal base back-end that will communicate with KVM. So going forward, MirageOS will run either over Zen or over KVM. IBM also have implemented this UKVM, which is a sort of reduced version of KVM specifically for unicanals. Someone also did a prototype bare metal back-end for Raspberry Pi. That's not in the main branch. So just say building for MirageOS. Basically you configure for the back-end you want, Unix or Zen. You do a make and you have a small executable. Just a Hello World example is, I think it was 2.5 megabytes for the Unix and 4.5 megabytes for the Zen image. Some examples of the use of MirageOS. There's the Piñata. This is Unicanal, which is online. You can reach it at this address. This is basically a small application that contains 10, I believe it's now 14 bitcoins, and you're invited to attack it. I think it's been up for about five years. We've been about 100,000 targeted attacks. In theory, the best they've achieved is denial of service. That said, there might be people who are more interested in breaking security other than to recuperate the 10 or 14 bitcoins. So it's not a proof of the security, but a good example. There's this example, Peggarten, who are preparing to deploy MirageOS for some sort of payment, obviously, credit card system they have. They initially tried to run these as AMI images. Found that too painful. Now with Solo 5, they're able to do that under KVN on Google Compute Engine. There's some tooling which is starting to be developed. There's EMC Dell. This is basically the Cloud Foundry spring boot people. They've been working on a sort of common front end for different Unicernals that exist. So here are some Rump Run OSV. OSV, I didn't mention specifically. OSV can actually run the JVM, which is moving a bit away from the purest Unicernal concept, but we have a choice. I've already mentioned IBM's Solo 5 project. It's being integrated into MirageOS and the UKVM. OSV also has a capstan utility for building. Both Unic and capstan also have some sort of image hub behind them. I mentioned the idea of just in time. So there is a Unicernal called Jitsu, MirageOS, which can then be used as a DNS server, which will launch on demand a backend Unicernal. That's been tested with MirageOS and Rump Run. But I think what's more interesting is Unicernals and containers. Why did Docker buy Unicernal systems? So you should know that already these people are actively involved in MirageOS, one of the main Unicernal projects. Unicernals are already used as functions with the implementation of Docker for Mac. But what's more interesting is what's going to come, and I think it's a no-brainer that we can expect that Docker will make the build, ship and run of Unicernals simpler. So running out of time, I'll move quickly on that. And I think we can expect secure container deployments, which are basically hybrid, maybe having Unicernals. They have some front-end functions such as the TLS tunnel. And I'm sure that when DockerCon, either US or Europe comes around, I'm sure Docker will have some surprises for us this year. So I wanted to do a demo. I'm running out of time. That'll be quick. So I just wanted to go to this site to defer panic. So this is basically a YAS. It's in beta, and they allow you to run some Unicernals. So here's one I created earlier. I'll actually say here in the dashboard of images, I have no images. I'm going to create one. So you can't really see this, but up here, I selected a Rump Run Unicernal. In fact, in this menu currently, we have Rump Run OSV or Include OS. And then I should just select the language. There's a selection of Go, PHP, Node.js. OK. Maybe that did succeed. OK. In the interest of time, I'm going to move on to another demo. But just know that basically this defer panic, you can create an account and experiment with Unicernals on their site. I've just a very quick example here. So of Runtime.js, this is one that integrates Node.js. Basically, this is a very small Node.js program with a bit of HTML here and then just some JavaScript to show an alert. OK. We can see that we have a 1.6 megabyte Unicernal. And if I do npm start, put launch commute. I go back to my browser quickly. OK. So I get the JavaScript pop-up and then the HTML. There's also this guy here based on his talk, Lukman OS. He put together a vagrant package with four different Unicernal demos. It's worth a look. So my conclusions, I mean, it's the Wild West. There are still 10 to 20 Unicernal implementations and some of them are moving quite rapidly. But a lot of work needs to be done to make them easier to build and deploy and debug. Debugging is possible, but it will be more like debugging an embedded application rather than a standard application. I'm pretty sure we'll see easier to use solutions. I'm sure Docker are going to help a lot here. The Solo 5 project from IBM will help and also Unic from EMC Dell. And I think we'll start to see some synergies between the different Unicernal projects. I know that HALVM, which is based on Haskell, I know they're considering going with the Rump Run maybe for the next release. They're an interesting complementary technology to containers and I think we'll see hybrid solutions. This won't be the solution for all cloud. And I believe that 2017 will be an interesting year for Unicernals between the various Docker columns the release of Mirage OS version 3 and some services that start to come online released in Proof of Concept. I have a list of resources there, but that's it, out of time, perfect. Questions? Sorry, which one? Okay, I'll treat with a link to my slides. Embrace Unicernals. And then we'll start running our apps as Unicernals. But then we'll need two links, especially for debug. Our app is running slow, so we need Perl on Linux. Oh, how do I run Perl for Unicernals? I can't. So I'll have to put counters in my hot browser. Wouldn't we end up like Graeme Leventin the whole operating system we have? Just like in HyperWide. Maybe we should just use existing hardware features in the existing operating system to separate applications. So, I think for some... Flames and stuff, I think. No, it's a common question. On the one hand, you'll be able to do functional debugging like with Mirage, you can build to a Unix backend. But obviously, yeah, if you want to test performance, then you need real debugging tools. And yeah, though we need for tooling for that. I don't know to answer more precisely your question. There were always the trade-offs between these things. But I'm sure that some tooling will come. It won't be as elaborate as on general-purpose OSes, but there will be some. Yes, that's right. Okay, so the question is, is there some way of having configuration externally? Because, yeah, I didn't labour the point with a unicernel application. You actually compile the configuration into the unicernel itself. Short answer is I don't know. I'm sure, yes, there must be ways, but I'm not sure what mechanisms you would use for that. Yeah, again, it comes down to usability. It's something that isn't very nice to have. Yeah. Yeah. Well, if you're running over an hypervisor, I mean, you'll have to manage that. Maybe Docker will have a solution for us there. Yeah? It's an easy way to run a Python app that utilises multi-processing, that uses multiple virtual CPUs or real CPUs. And which stack would you recommend for that? Okay, so the Rump kernels, so Rump Run in particular, sorry, yeah, the question was, is there a way to be able to run Python apps on multiple CPUs and so on? So Rump Run is, I think, the best option to run Python, first of all, but that doesn't answer your question about multiple CPUs. I guess you would... I'm not sure what the best answer is, but you probably have to split your application up into several unicernels, which sounds tricky. So microservices? Yeah, yeah, definitely. So microservices for a repeat answer. Okay, I've had enough signals. I'll stop.