The following is a transcript of the audio you can listen to in your podcatcher or the player above.
I had a briefing with Ian Eyberg, CEO of NanoVMs today.
Who is NanoVMs?
NanoVMs makes software to help you create and deploy unikernels. In this briefing, Ian discussed with me the state of the unikernel ecosystem and how NanoVMs fits into things.
Quick context for you if you don’t know what a unikernel is. Quoting from unikernel.org, “Unikernels are specialised, single-address-space machine images constructed by using library operating systems. They are built by compiling high-level languages directly into specialised machine images that run directly on a hypervisor, such as Xen, or on bare metal.”
A big point with unikernels is that of security. Since unikernels are single process with a minimal attack surface, they aren’t interesting targets for hackers. A hacker can’t do anything with a unikernel, even if they were to find a vulnerability.
If that context didn’t help, search for datanauts + unikernels for several podcasts we’ve recorded on the subject.
Let’s jump back to the conversation I had with Ian.
One point Ian made was that unikernels, even though you haven’t been hearing much about them lately, are seeing a lot of interest and adoption. Unikernels are in production in shops both large and small, and there are several startups in the space.
That said, there are some barriers to unikernel adoption, the main one being that they are a challenge to work with if you come from a typical operations background. You gotta create the unikernel before you can deploy it, and making a unikernel isn’t like firing up apt-get and installing all the stuff you need into an base operating system until you get to a golden image.
Instead, unikernel creation requires working with source code and binaries, compiling everything required for the machine image to run. That’s a knowledge gap for many operators, as most of us aren’t really systems-level people. We work above that layer.
This is at the core of what NanoVMs helps with–handling that system level work that’s required to make a unikernel so that anyone could do it using their GUI.
Speaking of their GUI,
I did get a passing glance at it at VMworld in late August. Ian was there at the NanoVMs booth, and I did an on-the-spot interview with him for our YouTube channel, so Google Ian Eyberg and Packet Pushers if you want a distant look at the GUI through the lens of our camera.
In addition to helping you create unikernels,
NanoVMs helps you deploy them.
Maybe you’re equating unikernels with just a different sort of container, and thinking that you’d rather use Kubernetes for unikernel deployment than NanoVMs tooling. Ian pointed out to me that while unikernels have many parallels with containers, they are different beasts.
Kubernetes is very good at container orchestration, but not optimized for unikernel orchestration. You’d actually be incurring a needless performance penalty using K8s to deploy unikernels. So, sure…you COULD integrate NanoVMs with a Kubernetes environment, but Ian is pretty sure you don’t actually want to do that.
Furthermore, the unikernel orchestration process will vary depending on the unikernel use case. Unikernels are finding uses in IoT, embedded systems, NFV, edge computing, and cloud infrastructure. Those use cases differ dramatically, meaning a different sort of orchestrator might be appropriate in each. Kubernetes isn’t a fit everywhere.
Another issue I raised with Ian about the barriers to unikernel adoption is that of
I’ve heard operators complain that it’s hard to deal with a unikernel, because they can’t get at the thing in the way they are used to when there’s a problem. Ian has heard this objection as well, but says it’s really a strawman.
Ian points out that tools like strace still work. Plus, NanoVMs deploys into KVM, so you’ve still got all of that KVM tooling. Also, teams supporting unikernels need to remember that unikernels are single process systems, so there’s no guessing as to which process is the issue if you’re troubleshooting the classic “the application is slow” problem.
Beyond that, it’s still possible to look at open files, as well as CPU and memory utilization. And you’ve still got logging. You can build instrumentation with Prometheus. There’s a lot available to operators.
Besides that, Ian argued that containers and serverless have most of the same support concerns that unikernels do, but that these are all increasingly well known problems with ready solutions.
For more information,
head on over to nanovms.com. And if you take them for a test drive, let them know you heard about them from the Packet Pushers.