Unikernels and NanoVMs

Video size:

0:09 Miko Pawlikowski

Hello and welcome to another episode of Conf42Cast. My name is Miko Pawlikowski and today my guest, Ian Eyberg, the CEO at NanoVMs. Hello Ian, how are you doing today?

0:21 Ian Eyberg

Hey everybody, doing good. Thanks for having us on the show.

0:24 Miko Pawlikowski

And today we'll be talking unikernels, unikernels and unikernels, to give you a little reference. But before all of that, Ian what's your favorite, most favorite thing about space travel?

0:35 Ian Eyberg

You know, rockets are kind of like bombs with a hole in them. So God bless Elon Musk, but I just don't think that's gonna happen for our travels to Europa and Mars and Pluto, that's my opinion, though.

0:52 Miko Pawlikowski

Is that the fact that they blow up continuously?

0:55 Ian Eyberg

It's just a very inefficient, very dangerous way of traveling. I think there needs to be a completely different method of travel, if we're actually going to go anywhere, do anything. I suppose it can kind of get you off planet, but that's about it. You know, there's this company called JP Aerospace over in Nevada, which is over the border from California, and they have this thing called floating to space. And what they do is they create these blimps if you will, and it goes all the way up to the edge of space, like 70-80K up, and then you can launch a rocket. And so you get rid of all the drag of the earth. And I always thought that was a much more sane method to get there. And it's way cheaper too, so there's that.

1:43 Miko Pawlikowski

Okay, well, hopefully you're listening Elon, you're doing it wrong. So I bumped into Ian recently, when I was researching unikernels, and trying to see where they went. Because they were all the rage about what 2015, 2016. And then I was expecting to hear a lot about them. But I wasn't. So we've got an expert with us today, the CEO of NanoVMs, who has been pushing that. Ian, what's a unikernel? Let's start with that.

2:12 Ian Eyberg

I guess, important to note that there's like well over 10 different unikernel implementations out there today. And so every single one has a little bit of a different take. But you know, at least from our point of view, what they really are, is a way of provisioning a single application, like one and only one application as a virtual machine. And it's really just focused on doing that one, you know, the program. So there's no concept of all this other stuff that comes with a general purpose operating system. Generally speaking, you know, not just us, but all the other unikernels will say that they're a lot faster, a lot safer, you know, with very varying degrees of precision on both of those claims. And then one thing that we've noticed with our own users is just the simplicity benefits that come with them versus something like a case, or something like that. But yeah, that's, uh, that's, that's what it is in a nutshell. It's another way to deploy a Linux application without Linux. And just making it run faster and safer.

3:11 Miko Pawlikowski

Okay, so some people actually call it library operating systems, right? Because you basically, I think it might be worth for the benefit of the audience. I saw this repeatedly being commented, why would I spin a new kernel for every application that I do want to start, right? So I think it's probably worth emphasizing that the whole idea is that you only put the bits that you need inside of that kernel. Right? If that's correct?

3:36 Ian Eyberg

Right. And, you know, to address that kind of question right off the bat, one of the reasons you would do that is because of security. Comparing and contrasting to say, containers, and so forth, containers share kernel. And that's honestly, like, one of their number one security issues is because of that. If you were one container, you basically have roof over all the other containers, and in Kubernetes, that just gets exasperated because Kubernetes spans multiple servers. And so now, it's not just like one server that you have control over. It's all those servers. So that's actually a really strong security argument for having the kernel. But the other thing that I think, why people ask this question is, it comes from kind of a misunderstanding on how these things actually get deployed. A lot of people think you're going to Amazon, you're spinning up a Linux, you use something like UPS, and then you run all your unikernels inside. And yeah, that does sound like a lot of extra crap that you have to deal with. But that's not what we do. What we do is we take your application and create like a new EC2 image out of it, a new AMI is built on every single deploy. And when that spins up, that's all that's running. So I think that question is a very common point of confusion that people have on like how these things are actually deployed.

4:55 Miko Pawlikowski

Okay, so let's bounce back to the security question, because I see it listed on pretty much every one of this kernels. I understand that the primary reason why, well for this argument, is that the reduced attack surface is basically removing the code that you don't need, right? That makes it more secure by definition. The counter argument to that is that for something like Linux kernel, it's a pretty popular piece of software that a lot of people run. And so when the bugs are being found, they're fixed reasonably quickly. And there's a good chance that if you're running, you know, reasonably recent version of the kernel, someone has bumped into that and fixed that. With a unikernel, on the other hand, that means that we were kind of thrown out of the other way and we're starting something new from scratch. So how do you make people feel a little bit better, I guess, about that aspect?

5:50 Ian Eyberg

Yeah. And that's actually a very fair criticism, you know, out of all the different criticisms that one could have, that's actually very fair, you know. This code is brand new, why should I trust this code over code that's 30 years old? That's totally fair. What I would say is, if you look at a lot of the other stuff out there that talks about unikernel security, they're always talking about attack surface, attack surface, attack service. To me coming from the security industry, I couldn't care less about that. Yeah, you can mathematically say, for every 1000 lines of code, you're going to find one bug or two bugs or whatever it is. But I really couldn't care less about that. For me, it's really about the single-process nature of unikernels. And that is the whole idea of an attacker breaking your software breaking into your server. The whole impetus for them to do that is to run their code on your server. They really couldn't care less about a pirate code. That's just like the entryway to the house that they're breaking in. Once once they're in your server, they want to run MySQL, or they want to install a crypto miner or, you know, any number of other programs and unikernels just explicitly prohibit that in the general case. But that, to me is like the the bigger security benefit of running unikernels. It just raises that bar up so much higher, because it doesn't really deal with the vulnerabilities that exist. Those are always going to exist, they get created every day, because that's what we do as software developers. But they do deal with exploit payload mitigation. That's to me the biggest benefit.

10:57 Miko Pawlikowski

Okay, so this is very interesting to me. And I'm kind of glad that you threw in some numbers. So is what you're saying that the bulk of the 200 or 300% increasing speed that you mentioned, coming from the single process model?

11:13 Ian Eyberg

Yeah, so just to be more clear on that. Nano is a single process but allows multiple threads. So if you go to Google, and I think the largest instance you can spin up with a number of threads, like 384-386, threads. If you have a program that can deal with that intelligently, you can scale as vertically as you want. Now, a lot of languages like your Node, your Ruby, your Python, any of the interpreted languages, those are all single process, single threaded to begin with. And so back in the day, I say back in the day, but people are probably doing this today, if I want to scale a Ruby application, I might have nginx in front, and then we have like five or six workers behind it. It's the same thing in unikernel land, except those workers become individual VMs instead. So you're still doing the exact same sort of horizontal scaling in languages like that, because those languages are just the way they're made, they're inherently kind of stuck in that paradigm. Keep in mind that a lot of these interpreted languages are just as old as Linux, right? They're from the 90s. So there's certain constraints of that time period, which is why they exhibit some of this behavior. And I think it's really great that we have newer languages like Go and Rust and languages like that, that are really starting to embrace the multi-core future that we're in. And I mean, you know, it's only going to grow from here. We're way past scaling CPU frequencies, way past that. So it's time that developers really need to start embracing that, whether they want to or not.

12:46 Miko Pawlikowski

So that actually makes me think of two things. And forgive me, if they're naive, just kind of try to explain to me like to a five-year-old. So first of all, would you not be able to get some of that same benefit if you just did some CPU pinning for your processes running on Linux? And second is that you rely on the hypervisor, and it looks like most of the time, you're going to be running on something like KVM. So under the hood, you're still going to have that process that's being switched between CPUs, and that process is going to implement your VM, right? So some of that cost, you can't really escape it anyway. Unless I'm, you know, not deep enough in the understanding of that.

13:30 Ian Eyberg

Yeah. So I'll address that second question first, with the hypervisor. Nanos like and pretty much many of the other unikernel implementations out there, they're not built to run on bare metal. A lot of people have this idea that I'm gonna go flash on Raspberry Pi with my unikernel. And that's what it's built for. I think that's a very, very, very niche use case. I don't know anybody outside academia that is doing that. That's it. When we run Nanos on CNR Pi 4, we're still using a hypervisor. Why? Well, you know, in the future, like, already, you can get our Pi with four threads. And now it's going to be like eight threads here soon, that hardware is going to continue to progress. And it just doesn't make any sense to take over the entire server. But we're always running as a VM at the end of the day. There's never a case where we're installing to bare metal. And so that hypervisor tax or whatever, that's always present. And it boggles my mind. But there's a lot of people out there that don't realize that the entire public cloud is completely built on virtualization. Like every single public cloud is entirely 100% virtualized. Amazon, Google, it's all virtualized. And so if you're deploying to your public cloud, you are already sitting on a hypervisor. Unikernels embrace that by deploying and using those native cloud facilities. So like, you know, the cloud native community can say, 'Oh, we're cloud native' and unikernels can be like, 'Well, we're like hyper hyper cloud', because they're almost even a layer below. As per your CPU pinning question. Yeah, you can pin to CPUs and so forth as well. But again, a unikernel being single process versus something like Ubuntu server or Debian server, there's just so much more stuff on there that is going to fight over those threads. So if you have 24 threads, great. But if you have like one or two, I mean, you're going to, you're going to have some performance taxes. And so, you know, we get asked all the time, well, isn't it just like Alpine Linux? And you know, set comp applied on it? And it's, if the answer is no. Even Alpine, whether it has a small file system, or you know, just a handful of programs, it's still Linux at the end of the day. And what I mean by that is, it still has the concept of users, it still has the concept of multiple processes, it has shared memory, it has all these concepts that belong in that multiple user, multiple process world. A world that was invented in 1969, 50 years ago, for computers that took up entire walls. That's not the world that we live in today. You know, even back in 91, when Linus produced Linux, we were working on 386s and 486s. Okay, so we still didn't have SMP processors, those didn't really arrive in a commodity form until 2000. That means we didn't have real threads and Linux until like 2001. When NLTP came along. We didn't have virtualization in a commercialized form until Citrix and VMware came out, again, in the 2000s. You know, it was still a solid 10 years before we could even really do something. Going back to what you were talking about, library operating systems. That was a concept of the 90s. But they couldn't really embrace that, because threads, s&p, virtualization, none of that had really been produced to the market yet. And those were the three kind of horsemen, if you will, that really kind of allowed this technology to take place. So it's kind of a function of the technology and where it was at the time.

17:11 Miko Pawlikowski

So we keep touching upon the kind of lightweightness nature of this unikernels. And I think a lot of the criticisms that they do get is around, 'Okay, so that's really cool. But how do I debug it? I don't get my favorite tools. I don't get my, you know, usual stuff that I typically get. And doesn't that make it harder to, for example, now that I've been breached? If there is nothing in that VM that actually keeps any trace of that?'. How do you address that? And what's the latest in kind of making it better and helping people to potentially make the transition between a standard Linux environment and the unikernel?

17:51 Ian Eyberg

There's a handful of questions in there. One is just general, how do I debug these things? So one thing that should be pointed out, and this is honestly something I could mention, but it's just gonna fly over people's heads until they try it out until they deploy their first unikernel. But these things are not like Linux. And it's just something that until you deploy your first unikernel, you're not going to understand fully. When I say they're running a single application, one and only one application, that's literally what it is. So if you wanted to SSH into your, you know, your Debian server, that's not the same thing as like, SSH into your application. You know, if I have a no js application, I don't like SSH into it to do random tasks with it. I might instrument it, so I can collect GC information, you know, collect memory growth over time. I might ship out logs via syslog, so it goes to Elasticsearch or Splunk, or something like that. But the whole concept of popping into an instance and trying to debug the actual server versus your application, that's kind of this head change that people have to get around. And they have to realize that no, it's really just your application. Let me give you some examples. Let me throw my DevOps hat. I have a server that pager duty just blew up my phone on. So I'm SSH-ing in and oh, well, actually, I can't even SSH in because the disk is full. Why? Well, turns out the disk was full, because nobody stood up log rotation for, you know, some cron job that was going on. And that's like one example. Another example would be, I pop in and something's opening up a 1000 different connections in span of a minute. And I'm like, 'Wow, which process is doing this?'. You know, so I whip out LS off and I try to figure out which process is opening up all these connections. All these different examples that I bring up, they always come down to the fact that I never really know which program is actually causing the issue to begin with. And unikernel land, you already know, because there's only one program. And so then, you know, once I isolate the program, what do I do? Well, I would go off line and try to reproduce the problem, right? The whole debug and production thing is something that unikernel culture, if you will, just kind of frowns upon. Most DevOps and SRE people aren't going to be able to just whip out a patch for whatever program that they're looking at anyway, they're going to try to mitigate around the problem. That's one of those things there. But suppose you do want it to bug, you know, like, we have explicit instructions to attach gdb to it and start poking around. You can instrument it with Prometheus, you know, all the instrumentation stuff works, all the APM stuff works. We actually wrote a custom APM agent, specifically because there were a few unique things that we found we could do with unikernels. I'll give you a case example. The database that actually backs that thing, we crashed quite a bit, because we were still working out some issues. And so what we could do is we could take a snapshot of the entire VM that runs on Google and then export it as a disk image, download it and run it locally and pinpoint the exact line where it's crashing. You can't really do that with the Linux VM, because there's all this other stuff running inside of it, right? But with unikernels it's only that one application, it becomes trivial to figure out what's going on. So yeah, there's lots of different ways of debugging these things. And I would just also in with the fact that asking that question is kind of asking, like, how do I debug our Heroku app? Or how do I debug a serverless app? Or in some areas, how would I debug a container running and some hosted environment? It's all the same sort of question. And you know, there's different ways of doing these tasks in these different environments.

21:38 Miko Pawlikowski

Yeah. And I think that kind of goes back to the mental model shift that you were describing, because for me, when I was looking at it back few weeks ago, I was like, 'Oh, no, I'm not gonna have my eBPF. And I like my eBPF'. So what's the equivalent visibility onto the lower level stuff of the kernel functionality that you built into the image that will be comparable to something that you can do with eBPF today? Is that something you're trying to provide for?

21:38 Ian Eyberg

So there's a couple of different things, right? You know, things like S trace and F trace, we actually have almost direct equivalence for. So if you need to go profile something and produce a flame graph. I mean, we use these tools internally, just to hunt down things. So there's equivalents there equivalents can be written. One way to kind of twist this question is what tools can I use interactively in production versus a dev test environment? And again, what we would say is instrument the stuff that you care about. And if you truly are trying to "debug" something that should probably be done locally to begin with. But yeah, a lot of these tools exist, like I said, the S trace, the F trace and all this other stuff.

22:51 Miko Pawlikowski

What about the networking stuff, the stack. What visibility do you get out of the box, if you go for example with NanoVMs?

22:58 Ian Eyberg

Yeah, so networking, same thing. So, you know, networking is, and this is something good to touch on, coming from a container Kubernetes environment. Those environments, duplicate the network stack, they duplicate the storage stack, this is what actually slows them down, compared to say, in normal native Linux. And so there's lots of different ways to shoot yourself in the foot. But there's also lots of different ways you can kind of expand and do various things. A lot of those tools still exist, right? You know, in some cases, the clouds aren't going to allow you to set up promiscuous mode and start sniffing the traffic for security reasons. But if you have your own stack, your own servers, you know, you can totally do that. We operate at that same sort of layer. Locally, if you run offs, you might use user mode in a dev environment and prod, you know, Google's going to spin up a tap interface, they don't call it just tap interface, right? They call it a, 'here's my elastic network adapter', or whatever. But under the covers, that's what's going on. So it's so it really depends on where you're deploying to, and what you're interfacing with. Not sure if that answered the question.

24:06 Miko Pawlikowski

No, it does. You know, obviously, it kind of sounds scary to be like, 'Oh, I've really grown to like this tools now'. And switching to anything else sounds like jumping a little bit into the unknown. But that's what progress always looks like at the beginning, anyway. So I think we kind of covered a line notes of the really more popular kind of criticism that I've been hearing about, and one that we maybe haven't touched on directly is that a lot of people just say that containers and micro VMs are things like G visor, or if you want to be a bit more exotic, they kind of give you a lot of these benefits that unikernel provides without having to actually change the environment and having to recompile the kernel over time. How would you address that?

24:54 Ian Eyberg

Again, a couple of questions here. I'll start with that very last one recompiling. So again, being very different than some of the other implementations out there. We don't recompile your application. We think that's basically a non-starter in our opinion for most people. There's a lot of software that people use that they don't necessarily write themselves. So that's a huge ask for many people. I mean, a lot of people look at why Docker exploded to begin with. You know, sudo app get installing and editing some config file was already enough of a pain in the ass for most people. So asking them to recompile from scratch is just not happening. So we don't do that. We load draw elf binaries, and if it runs in the unikernel paradigm, it runs in our system just fine. As for G visor firecracker, we can touch on those really briefly. First off firecracker, you can actually run nanos and many other unikernels inside firecracker. Firecracker is not a competitor to unikernels, it's complimentary. So if you need certain guarantees that firecracker gives you, namely that is faster boot time at the cost of lower runtime, then you can totally use it today. We have tutorials, and so do other unikernels out there. That was really meant for serverless and also fast instantiation. I should point out that if you're going to shove something like say a JVM inside firecracker, it's not going to boot that fast, right? You know, you still have the boot time of your app, if you have a Rails app. It's like firecracker. That's not That's not what it's for it just, you know, buyer beware on that sort of thing. gVisor, we can look at that. So gVisor basically addresses the container security argument head on. And it's basically Google saying, 'Hey, we understand containers are not a security primitive at all'. And so they offer gVisor and gVisor is... Google has this habit of having these projects inside Google. They basically twist the name and completely rewrite it and then release it as open source on the outside, gVisor is one of those projects. gVisor is is different, though, because what they released, it relies on hardware virtualization to actually perform in a manner that's acceptable. So by hardware virtualization, I'm saying it's using the exact same sort of underlying stuff that unikernels and typical VMs are using at the end of the day. Now, if you're not using that, which is the fault case, if you're running it on any of the clouds, it's going to use ptrace. And so anybody who has ever touched ptrace knows that this is going to make it insanely slow. So I don't really understand where gVisor is going in terms of what they're trying to do. I don't know. But ptrace is just kind of a nonstarter in my opinion for for prod workloads. Containers, obviously, all these companies and everybody's using containers, you know, if people are happy with that, keep going at it. There's a few other projects in the space. But yeah, in general, it's not something we're really competing against technology-wise. I think you brought up eBPF. And maybe that's worth jumping into a little, compare contrast. That definitely has lots of interesting use cases, like you mentioned, tracing various things that you might be interested in. That, in my opinion, is its main, predominant use case, getting performance characteristics of lots of things. But there is a small contingent of developers out there that are kind of arguing that it's going to be some sort of new application runtime, and that I think people are so far off on, mainly because they don't know some of the constraints that it has. Things like the no unbounded loops rule. So that's basically say, no do Wiles. At first blush that says, 'Okay, well, I'll just do a for loop and you know, capita, whatever'. And, but what you don't understand is that there's lots of other things that that prevents. Greedy algorithms that are commonly used in pretty much every standard lib of string libraries. So your strict whitespace at the end of the string type of things, your reg x's, lots of those different things. And where would I use this? Well, practically most applications. So yeah, for reasons like that, I don't see eBPF being this new application runtime, I do see it getting lots and lots of DTrace style, like observability into your applications. And that's where its sweet spot is, is getting that performance profile now.

29:28 Miko Pawlikowski

Let's switch gears a little bit and helped me out. I've been trying to kind of come up with an example of a perfect application for unikernels. You know, the killer app equivalent. From your experience, you've been at it for quite a few years now, what is the most attractive use case for unikernels that people actually do today?

29:49 Ian Eyberg

I mean, and I'll just preface by saying that I don't really believe in the whole killer app thing anyways. Because all the technologies we talked about, for instance, none of them have killer apps. They they have users that are deploying normal software for them. But yeah, in terms of like the end users and customers that we have, like, what do they actually use this for? It's all webapp software. So it's all web apps that they might be deploying to any number of cloud systems today, you know, if they're writing Go, and they're deploying to Google, if they're writing Rust, and they're deploying to Amazon, you name it. I mean, the public cloud ecosystem, and all the software that resides on it, is absolutely massive in terms of scale. And what's what's really funny is that that actually only really represents like 3 to 5% of North American computing to begin with, just kind of a mind-boggling statistic. But that's both something that the head of Google Cloud has mentioned and both Diane Greene, who was the ex-CEO of VMware. So any software that you'd be tooling to a Linux VM in the cloud today is kind of what we target. And that's what people are using it for right now. I think the most popular workloads are probably Rust, and then Go probably be in a second. But we don't track anything, we don't have any kind of phone home telemetry included by design. The only data we have are from customers that we interact with. And then the package repository, we've added some lightweight download counts and stuff like that, too.

31:27 Miko Pawlikowski

Ian, how did you get into unikernels?

31:30 Ian Eyberg

Good question. Just a preface, we did not invent this. I was reading a lot of the papers that were coming out of, you know, the Miraj crew, which is later on they formed unikernel systems, and then they were acquired by Docker. So at that time, and like 2013-2014, I was reading a lot of their papers. And there's other stuff in the space too, like OSB that was ran by cloudy Asus systems that kind of pivoted over into facility V, which is a Cassandra replacement. So just playing around with that stuff, and you know, just getting super, super interested in the ecosystem and then was wondering why nobody had written a good Go unikernel. Go was the language I was using quite a bit at that time. And so we kicked off the project to make Go rump, which was a Go implementation in rump run at that time. And I booted that up on KVM. And I was just like, 'Oh, man, this is totally what the future is going to be like'. Because it was so painfully clear, you know, again, coming from the security world, that's what initially attracted me was the security implications of it. And then I started seeing the performance. And I started saying, 'Man, this is, you know, the amount of software that people were diving into, you know, microservices started being a thing around that time'. And so all that together just kind of threw me into the vortex of unikernels.

32:56 Miko Pawlikowski

And at some point that became NanoVMs.

32:59 Ian Eyberg

Yeah. So NanoVMs was actually a different company at one point, and focused on APM type of stuff. And then we started building out infrastructure to kind of host our own apps. And then, you know, started doing all these patches and so forth. And eventually, it became kind of clear that to kind of really take it in that direction, we had to write our own kernel. And so, I think it was around 2018, was when we started writing Nanos. And just a word of caution to anybody that's thinking about doing the same thing. You know, Linux is 30 years old right now. And so it's a shit ton of work to write something that's even halfway decent. Anybody can kick out a Hello World bootloader in half an afternoon, that's pretty easy to do. It's only five full bytes, right? So it's pretty easy to do. But you know, add in the networking stack started supporting many languages and start doing all this other stuff. And then, on top of that, say that you're faster than Linux, say that you're more secure stuff like that. It's a lot of work. I don't think people understand how much work is actually involved. And so going to some questions, oh, well, where are unikernels? Why haven't I heard so much? Blah, blah. You know, what happens is a lot of these implementations, they get initial bit of traction, they might get a grant, they might get a little bit of seed funding or whatever. And then like, they don't get enough done before they die. And that's literally happened to so many of these organizations out there. I'm not going to name names, but you know, pretty much all. It's that much work. And so, you know, we fought tooth and nail to kind of get resources into the company and carry on the mission for a while now. But we're pretty comfortable where we're at right now. And so we don't we don't think we're going to meet the same fate.

34:57 Miko Pawlikowski

So did you kind of start at knowing, 'Okay, that's gonna be a lot of pain', or were you...

35:03 Ian Eyberg

I had a fair idea it was going to be some pain, just knowing the amount of work. I don't think I took in how much work, but I understood that there was going to be quite a bit of work involved.

35:17 Miko Pawlikowski

Fair enough. So let's talk a little bit briefly about, you know, kind of like the unique value proposition. Because as far as I understand right now, from the companies that actually offer a product publicly and are alive. Others, you guys and then there's the Unicraft, I'm not too sure what's the company structure behind, and that's about it, right?

35:39 Ian Eyberg

There are three others that I would say are alive I know, either have funding or have customers or basically are still working. Put it this way, they have employees, and they're actively working on it, there are a handful of others. Again, a lot of these companies have different takes on how to go about dealing with some of these issues. Some of them, it's less about dealing with issues and more about coming up with some of the benefits. But yeah, Unicraft, I haven't spoken to them personally. I know a lot of them were coming out of NEC. And they have for the past, what four or five years been publishing a ton of papers. I mean, that's the other thing. A lot of people are like, where's unikernels? Where's unikernels? And it's like, Have you looked at any of the conferences, you know, OSDI, HotCloud, like all these academic conferences every year, there's like, half the conferences, unikernels. So, if you're wondering where the research is, where motion is, that's where you should check it out. But yeah, they definitely have kind of the more pure approach where you pick the libraries that you want, it compiles the application, and you're off to the races. We haven't done any, like benchmarking or anything against what they're doing yet. But uh, but yeah, that's, that's kind of one of the big main differences from them versus what we're doing.

37:07 Miko Pawlikowski

I saw on your website, someone wrote a copy "Run faster than the speed of light". Did you write that?

37:14 Ian Eyberg

I might have had a beer or something, I don't know. I wouldn't read into that whatsoever, it'll probably be changed in the future. It's not like a official slogan or anything.

37:27 Miko Pawlikowski

I was just laughing a little bit. I'm thinking Mr. Einstein is turning in his grave reading that, but...

37:37 Ian Eyberg

You can't disprove the existence of tachyon, is going back to our need for different space travel.

37:44 Miko Pawlikowski

Fair enough. So I just wanted to also touch a little bit because, you know, for us here in Europe, a lot of us picture a garage somewhere in Silicon Valley. What's your founder experience been so far? For something this technical and this, I guess, like you said, painful in a technical way. Because, you know, all startups are painful in their own unique ways. What's been your best and worst experience so far, if you were to pick just one of each?

38:14 Ian Eyberg

I spoke about how much technical work there is. But you know, that's just one side of the coin. The other point is, very few people even know unikernels exist. It's not like say, 'Oh, we're a database company. And, you know, nobody knows our database company exists'. It's like, no, they don't even know databases exist type of thing. I can walk down the streets of San Francisco, ying somebody with a hoodie on and saying, 'Hey, you know, what's a unikernel? And chances are, they're gonna be like, 'What?'. That's a problem, right? If you want to kind of take it to market you know, there's a lot of developer awareness, developer education, one of the reasons why we're talking on this show. There's a lot of awareness on like, getting people to understand that an option. That's something we're just now starting to address, because there was so much upfront technical work that had to be done. You know, nobody wants to come check it out, if all you can do is some crappy Hello World, right? They want something that works, something that not only works, but does what you're claiming it to do. So yeah, that's where we're at. In terms of like, the best and the worst. I mean, I would say the worst thing, just from a company perspective is, you know, I'm an engineer by trade. So that's where I come from, and there's just an ungodly amount of random bullshit that you have to deal with that has nothing to do with the tech, has nothing to do with cells, like literally has nothing to do with anything but just like managing the day to day of a company. And it's it's ungodly, how much there is that that you have to deal with and the sooner I can give that work to somebody else, the better in my opinion. The best, I would say the best thing is that, you know, you're the captain of your ship, and you know, your ship can sink in the ocean, if you let it. But you know, if you can take that ship and sail wherever you want to go, to me, that's really magical. So, you know, to be able to carve out a system, you know, the way I see it, it's like Linux is literally 30 years old, I've been using it since I was giving a handful of 144 floppies, being able to set like an entirely new direction for at least a certain subset of software. That's like super exciting. There's so much opportunity to do, so many things to explore. And, you know, I think anybody in my position has a sort of fountain of ideas going off in their head at any given time. And, you know, it's best to ignore most of that. But that's what creating a new ecosystem allows you to do is, you know, if not you, then you enable everybody else to, to kind of explore.

41:10 Miko Pawlikowski

Do you expect a Docker moment for unikernels? Or do you see it more as a kind of slowly growing niche for people who really care about one of the advantages? Or maybe a different way of asking this question is, where do you see them in, say, five years time?

41:28 Ian Eyberg

I wouldn't say there's gonna be a Docker moment quote. What I do see is, you know, a) our company is going to be around. We have enough customers and enough traction to where we're not going to be dead anytime soon, you know, we're basically self-guiding at the moment, so to speak. We can kind of do whatever the hell we want. There's lots of ways we can go. And you know, at least from the company perspective, it's really kind of going in and just really pounding through. There's so much software out there. A lot of people are like, 'Well, obviously, you're going to talk to the most leading edge organizations', and we do. But there's software that hasn't been updated in like 30, 40, 50 years. There's so much software out there that needs help. And so I see lots of opportunity to bridge some very long standing problems in the software world, I keep coming back to "The Cathedral and the Bazaar", not to track that into this conversation, but keep coming back to it. Because, you know, a lot of people were like, 'Oh, well, you know, open source, you know, change the narrative there. And, you know, pKH has kind of this opposite view that I share'. And he's saying that, you know, he has this paper called "The generation lost in the wilderness" or something like that. And he argues that open source was kind of dual-edged in that sense, where, you know, the Bazaar has lots of choices. But there's a lot of crap out there too. Not necessarily are arguing for the cathedral approach. But there are lots of problems that we can fix. I mean, I'll give one example, which I give a lot. libxml, libxslt, those two libraries are linked into every single interpreted language out there. And they're both fairly old, they're like 20-25 years old. libxml has FTP server in it, for God knows what reason. And I mean, you can find vulnerabilities and just, that's the state of our open source ecosystem. You know, politicians like to talk about bridges and roads falling down and stuff like that. But we have the exact same issue in open source, and unikernels offer this kind of unique way of coming in and repairing a lot of these bridges. Why? Because we don't have to throw the entire kitchen sink at a given application, come in and start doing all sorts of other interesting things. People have been talking about, like link time optimization, stuff like that, for years. Well, in a unikernel system, that's actually something that's feasible. In a Linux system, that's totally not feasible. There's lots of different things that can be done there when we get an ecosystem that kind of embraces some of this.

44:17 Miko Pawlikowski

Powerful stuff. And some really good examples too. So for anybody who wants to start with Nanos, I guess or was it Ops that they will be starting wit,h what's the easiest, what's the recommended path to go and give it a Hello World?

44:35 Ian Eyberg

Yeah, yeah. Either go to nanos.org, or go to ops.city. They both have kind of getting started guides that can get your first Hello World up in seconds. And you know, if you're feeling adventurous, you could be deployed to Google or Amazon or wherever in like minutes. And I would strongly, strongly urge like anybody that's interested in it, don't go read other articles, don't just go look for opinions. Just try stuff out yourself and form your own opinion. And then you can say, 'This is trash, or this is awesome'. Or you can say, 'Meh'. Form your own opinion by trying it yourself. And it'll answer so many questions you have. It's what I highly encourage people to do.

45:19 Miko Pawlikowski

Some of the articles being, what was it, 'unikernels are going to kill containers in five years', seven years ago. And the other one 'Oh, unikernels are not production grade' or something like that. None of which necessarily played out. Okay, if you were barred from saying the word 'unikernel' for about 30 seconds now, what will be any other technology or language or methodology or anything to look out for in 2022?

45:51 Ian Eyberg

One ecosystem that is interesting from an engineering standpoint. I don't, I wouldn't say it's gonna catch fire or anything. But there's a project called FireSim out of Berkeley, and it allows you to simulate exotic hardware on FPGAs running in the cloud. So what does that mean? It means, you know, for instance, when we wanted to add RISC-V support to the unikernel, how do you even test that? Because there's no RISC-V board that runs KVM today, because they just added the hypervisor, you know, the virtualization spec, they ratified it, like last August. So we actually today don't have hardware that can run it under KVM. But you can go to the cloud, and you can run a virtual implementation of that hardware. You know, the FireSim people are crazy. They didn't just simulate like one server, they have papers where they talk about simulating an entire rack of servers that don't straight up exist. And I'm not talking about VMs, I'm talking about like chips that don't exist. And to me, that blows my mind, because it opens up the door to again, exotic hardware that you don't have to go to fab for, you don't have to spend, you know, millions of dollars to create. You could just try it out in the cloud. And that's, I can't say that that's going to lead to some sort of Cambrian explosion, but it certainly is very, very interesting.

47:12 Miko Pawlikowski

Oh, you know, some people call it classic cars, some people simulate classic hardware. Everybody has their own thing. So I guess the last question for you, before I let you off the hook. From your experience, what would be like a single highest return on investment thing that you did for yourself, for your career, anybody can replicate? And it can be anything, you know, anything that you actually found a good return on investment on?

47:43 Ian Eyberg

I would say just explore and work on stuff that you feel like doing. I don't want to say follow your passion, because I think that's horrible advice at some point, especially if you want to run a company you have to clean a toilet. I do lots of things that I really don't like doing. It just has to be done. But yeah, if you're doing stuff at your job and you just you're like, 'I hate this', go find another job or like start your own or or do something else. Because it's just a waste of time. So if you're completely bored of computers maybe jump into a completely different, go explore philosophy or rockets or, I don't know, something else. But computers is pretty deep and wide.

48:27 Miko Pawlikowski

Not rockets, because they're terrible.

48:30 Ian Eyberg

Right. But yeah, there's that and you know, I guess on the tail end of that, you know, just work at it. I'm not saying budding the sea, you know, clocking hours type of work. But when you're working, work. Don't go to Twitter, don't go to Hacker News. Don't do all the time wasting stuff, just work.

48:51 Miko Pawlikowski

And I think that's a really good way to wrap it up. So everybody Ian Eyberg, a CEO at NanoVMs. nanos.org is where the unikernel lives. And NanoVMs.com, if I'm correct, is where you get the commercial support with all of this stuff. It's been a pleasure. Thank you so much. I think I've learned quite a bit about unikernels and what they are. Thanks for coming on the show. And I'm telling you already, we're gonna get you on in a couple of years time to see where it went.

49:26 Ian Eyberg

All right. Sounds good man.

49:27 Miko Pawlikowski

Thanks a lot.

49:28 Ian Eyberg

Bye bye.