 Hi. My name is Alok. I work at ID device. I think it's become a mandatory plug now. We're hiring, so do get in touch with me. So I'm going to talk about Unicornals. The original intention of this talk was I would actually have something to show you and I could get into some technical details, but that didn't happen. I have a bunch of insights and perhaps we can talk about those things. Let's start off by setting up the problem statement. It doesn't really matter whether it's running things in scale or whatever it is. Everything breaks, everything. No matter what you do, it's going to break. Building a predictable self-regulating system, it's really hard to do. Large variations in load, like the kind of thing that Vinay was talking about earlier. I'm sorry. Oh, you can't hear it back? Is this better? Yeah? Okay. So the kind of thing that Vinay was talking about earlier, 25x bike, that's really hard to engineer with. Again, it's really, really hard to have something that can handle 25 times load or 100 times load. It's really, really hard to handle both in terms of cost, complexity of the system that you have to deploy. You saw that deployment diagram that Vinay came out and that's the level of engineering that goes into it. You can achieve reliability by code, you can achieve it by process, by skill of the people who do it, and maturity, how many times you've done this before. And the one learning from that really is that don't use a human to do a machine's job. There's some things which are repetitive and all that and that's best left to machine. Try not to do this or engineer this sort of reliability on the base of people. You have a bunch of balances that you need to get to, so reliability versus agility. Agility, again, it's something that's nice, sounds nice, but it's pretty difficult to quantify it. Pretty much every business, and I'm guessing last number of businesses were here, they need it. They needed it to succeed because things change really quickly. The last one is complexity versus metrics. You can build a very complex system that means that you don't really have a good handle on whether, at any given point in time, how is my system? Am I running out of capacity? Am I underutilizing capacity? Could I move things? Could I do things better? Because there are lots and lots of things in the picture. There's network flows, there's application, CPU usage, databases. You need to put all of these things together and come up with a quantifiable thing, something that you can look at in real-time, something that you can understand in real-time. That's the other balance that you need to get to. As you can see, the problems of running web-scale applications or even your own small little product that needs to do this, it's hard to do. The current technology that we're talking about, for that I mean Docker, LXC, CH roots, whatever. Lots of other talks on those things, so I'll just leave that to those talks. For this, basically you have to build the images yourself. The building of your images, it's really up to you, but with the 5Is and you can't really trust anything that you download from the internet. You've got to build your own images. That has its own set of challenges that you need to build. The biggest practical problem is that when you're talking about images of the order of gigabytes, then that brings in a huge number of problems. You can use innovative things like Facebook, for instance, they deploy code over BitTorrent. That's great, but when something goes wrong or some particular part is not getting updated, I'd imagine that it would be a bugger to debug this and find out what exactly is happening. You need to do stuff like this when you're talking about images size of gigabytes. The amount of density that you can achieve, given X amount of compute power, that is CPUs, RAM, storage, whatever, you can get pretty much the same amount of density via containers as you get with VMs, shrewds. The attack surface is the same. In fact, probably a little more because in one server you're running copies. You have the same amount of attack surface. For instance, if there's a shell shock bug and your application doesn't really use Bash in any way whatsoever, but you still need to apply those updates, otherwise you're going to have a problem. Basically, with the current technology what you have is you're adding one more layer to the mix. By layers, you start off with the hardware at the bottom, and on top of that you have the hypervisor. On top of that you have your OS, your kernel, whatever you want to call it. On top of that you have your run time, whatever, your Python run time, your Go run time, whatever that is. Then you have your configuration on top of that. On top of that you have your application. Now, basically you'll add one more thing in between say your hypervisor and OS kernel. There'll be this sort of container thing that also sits in there. So you're adding one more layer to an already quite a layered mix. So with Unicernals, basically boil them all down to three layers. You have hardware, you have your hypervisor which provides two functions for you. One, your power envelope. So basically your hypervisor knows how to deal with your hardware. So supposing you were running on ARM hardware, the hypervisor would know how to handle the power envelope there. And the other thing with the hypervisor would provide you is resource isolation. So you would run a bunch of applications on top of that. And some of these applications need to kept isolated from each other. So this is an extreme view of Unicernals. Docker, I mean container technology I believe, is just a step along this path. I'm just taking a way out from left field type of view. And trying to see what we can do with that right now. So currently what do you have with Unicernals? The state of the art, so you have two different, you have two types of Unicernals. And this slide specifically, I'd like to give the credit out to this person called Mark Bojulaj. There's a credit slide right at the end. So I came up with this slide basically based on his work because I really haven't tried out all these things. So you have two types of kernels basically. You can call them thin and fat. So thin, you could consider them specialized, single. You have a very well-defined application, you want to do that. So that sort of thing applies here. And fat are more traditional. Most of these things, at least BST-Rumkernels for instance, they aspire to something like POSIX. So your existing applications could run on this. So some of these like link, drawbridge. Drawbridge is this new thing that's coming out from Microsoft of all things. Available in a shirt if you want to try it out. Link, OSB, Boxfuser. These are three that I know for a factor available in EC2. Boxfuser is actually another sort of integrator. So you can go out to their site and if you have Java applications, you can get it down to that. I don't know if you guys remember, way back in the day, there was talk of some building the Java VM right into their processors. This is basically the same thing. But instead of having to build a Java VM processor, you'd have a unique Java runtime that runs down there. There's lots of stuff. There's lots of real-world things that have been done with Mirage OS, OCaml. In fact, there's this person out of the University of Cambridge who's done a bunch of stuff and they've come up with, they had released something recently called Jitsu just in time summoning of unicorns. Erlang is something that's particularly suited to this sort of, this mode of building applications. So that's something that you could take a look at as well if that's something that you're interested in. So some, these two slides which have unicolonial pluses and the minuses, but as pretty much everybody knows, there's no such thing as an advantage. Every advantage can be disadvantage. You just need to look at it differently. So one thing, the first thing that I can come up with, you have images are usually of the order of megabytes, sometimes even kilobytes. You're in control of performance because you control everything. You don't have generic TCP offload in your Linux kernel which is doing something and you don't really know what's happening in there. So you know exactly what's happening. Order of magnitude in increase in density. I don't know if you guys have seen this theme party game that you can play on Facebook. It's provided by this company called Octro. So they use Erlang and they've got, they support twice the number of users per server than WhatsApp does. And WhatsApp, I mean, exchanging messages here and images and all that, reasonably complex. But there's a lot of computation that you need to do in, in team party. It's not just, you know, sending, you know, dump IO here and there. So, and with that level of thing, they've achieved twice the density. Deployments that you can reason about, primarily because your application is now aware of deployment. It's aware of like how it's running. It has to be, it has to be aware. Otherwise it's not just, it's just not going to work in this sort of thing. So your applications can sort of handle large amounts of load balancing, these sort of functions, right in the application layer itself, which means that you can do more efficient load balancing. Attack surface reduced, way, way reduced. For instance, you don't have all the craft that comes along with a big container image or something like that. You don't have any of those things. So basically your attack surface is basically going to be your application and stuff that happens in there. Everyone needs to be a complete engineer. I'll talk about that a little bit more. So the first three, primarily talk about efficiency. This one is just a kiss principle. This one's about security. And all of these, you could, you could take this whole slide and just make it unicals and minus minus. And I could bring up another set of things, but that, which is this one. So morphing existing application is not trivial. In fact, it's not really something that's going to happen. It makes sense for, you know, greenfield projects, stuff that you're starting out from scratch now. But existing deployments, you've got a lot of baggage that you had along, maybe not. And some software, like databases, like supposing you use an RDBMS, Oracle, Postgres, things like that. You might not find, you know, good solutions for that. Now I told you that, you know, you can get order of magnitude increases in density. That also means that hardware failures, if the hardware that's running something, if that fails, it takes out more of your capacity than it used to before. Resource isolation is kind of tricky because you're kind of depending on the hypervisor. The first few implementations of MirageOS and LibOS, they had like problems, you know, fundamental design problems with resource isolation. It's getting better, but you know how it is, right? It's impossible to guarantee that these sort of resources can be kept isolated, that there is no data leakage between them because finally these things are running on the same bit of hardware. So it's not easy to guarantee those things. And thin unicorns might not really be ready for primetime yet. I don't know of, you know, very many people. Okra was actually the first people that I found out who were running this sort of thing in production successfully. So I'm not entirely sure about the primetime thing. Everybody needs to be a rounded engineer. This I think is one of the big problems is that you can't operate at your abstract level of the framework that you're working with. It can't be like a web developer. A web developer needs to know what's the TCP stacks about because that's what's being demanded of you when you start writing stuff with unicorns. That could be an advantage, could be a disadvantage depending on how you like to look at it. Some of the applications that have used unicorns, virtualized network functions. So these guys, basically what you have is you have your hardware load balancer or whatever. You want to virtualize it the easy way, you write the equivalent C code of whatever it is and run it on Linux. But there's this click OS which is primarily about network interfaces and IO. And it has a bunch of things that you can offload a lot of packet arrangement into. So it provides you some primitives for that. So a bunch of virtualized network functions like F5 load balancers and I can't remember the other ones. But there are a bunch of virtual network functions which use click OS and are delivering, they're being sold right now. Service-oriented architecture based on microservices, it works quite well in this sort of thing. You can build persistent services, so the kind of thing that I was talking about earlier, databases. So they might not have good solutions in the unicorn world, but you can build a different type of persistent service. So persistent services are things like databases, they primarily rely on IO. So you can have a two tier thing, so you can have your application talking to a bunch of storage right at the bottom. And that is your persistent layer. So you could, in theory, you could build like a two tier, no SQL thing and you could generate infinite scale from it. Network services like VPNs, lots of things, lots of existing people do use unicorns for this sort of thing. So I have, these are some credits that I have of particular elements. I'm putting any links and stuff like that, Google's good enough for that. So these are the two guys who have done a bunch of stuff. In fact, Matt Pajor has a really nice presentation about unicorns if you want to look at it more. So I kind of, you know, this is more blue sky stuff. Things that I do when I'm out of the office, you know, sitting on flights and stuff like that. So I've left a little bit of time to hear what you guys have to say about it. If you have any comments, questions, that sort of thing.