Containers / Sponsored

Beam Me Up, Unikernel

7 Jun 2016 11:25am, by

“The really important part of whole unikernel movement has nothing to do with containers and virtualizations. With unikernels, it’s about librarification. All dependencies turn into libraries. If you look at the entire stack of application level things, people tend to build small libraries and reuse them. We’re trying to convince people that systems code can turn into libraries. You don’t have to rebuild every single time,” said Anil Madhavapeddy, a founder of Unikernel Systems, and now a member of Docker’s technical staff (Docker purchased Unikernel earlier this year).

There can be no doubt that the golden age of unikernels is fast approaching. Initially, developers thought that using unikernels in production was something that was still five years away, but companies are already beginning to use them in production today. In this episode of The New Stack Makers embedded below, The New Stack founder Alex Williams spoke with a trio of unikernel experts: Ian Eyberg founder of unikernel platform provider Defer Panic, Docker’s Madhavapeddy,  and Joshua Bernstein, vice president of technology at EMC.

The discussion can also be viewed on YouTube.

As the adoption of containers continues to heat up, people are finding there are things for which containers simply aren’t suited. The question is, are unikernels any better suited to these tasks? For Eyberg, the answer is unequivocal: ‘Yes.’

Eyberg also offered some choice words about companies offering containers as their own SaaS: “Containers are a part of the kernel, and the kernel is the problem. There’s many things that containers cannot do or won’t do. The whole containers-as-a-service thing is marketing bullshit. Until you can completely replace Google Cloud or Amazon (AWS) with containers it’s just bullshit, flat out.”

Making applications simpler to deploy and manage is something that unikernels can achieve. Companies such as EMC and Defer Panic are already taking steps to help break down complex workflow tasks into something more manageable by using unikernels. “Engineers like to be complex, but honestly, that’s a horrible way to go through life. You need to make things simple. This is where all our security and configuration management problems come from. DevOps people can make more money than a regular engineer, and that’s a bad problem to have. It’s all because we have a monolithic beast of a kernel that’s been in place since the 1960’s,” Eyberg said.

Bernstein goes on to explain that there simply isn’t enough time devoted to explaining to developers and ops teams how to configure their infrastructure to support unikernels. “Regardless of how we deploy applications, whether it’s on Google or Amazon, it has to run somewhere. Infrastructure doesn’t just exist in the cloud; it has to actually exist. I don’t think we talk enough about how to compose this infrastructure to support these kinds of technologies. Everyone is like, “Oh it’s up to the developer,” and the poor ops guy is sitting there with a server and a hammer going, ‘I don’t know what to do!’”

Madhavapeddy went on to explain that no matter how fast a central cloud provider is, unikernels come out ahead by addressing the physical server layer. “Compute needs to run here if you want to respond in 10 milliseconds. There’s no way a central cloud provider can pull it off. There’s physical limitations. We’re either going to be Star Trek, or we’re building better APIs.”

Capital One and Docker are sponsors of The New Stack.

Feature image: Leonard Nimoy and William Shatner, via Pixabay.


A digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.