Next-Generation Cloud: The Rise of the Unikernel | Hacker News Reader

Next-Generation Cloud: The Rise of the Unikernel

xenproject.org

132 pointssciurus32 comments

What's old is new... Unikernels are quite reminiscent of the VAXELN product from ~30 years ago; write the application code, link in the various services you need, and disk or network or ROM boot the results:

http://odl.sysworks.biz/disk$vaxdocdec953/decw$book/d33vaa48...

Of course in many ways "cloud" computing is just another implementation of a 370/VM mainframe system. I find the evolution fascinating. Oh and I had a comms processor (terminal server to a modem bank) which turned out to just be a MicroVAX 3 runing VAXELN. The CPU was some what "cut down" (I think optimized was the word they used) to make it more cost effective. VMS would not boot on it.

Is there a decent technical writeup of how the 370 worked in practice? I love hearing about the old mainframe tech of yore.

See The Origin of the VM/370 Time-sharing System by R.J. Creasy, http://lass.cs.umass.edu/~shenoy/courses/fall07/papers/vm370...

Sounds like LibOS: https://lwn.net/Articles/637658/

https://news.ycombinator.com/item?id=9259292

Or Service Virtual Machines: http://alt.folklore.computers.narkive.com/LXzjsdU7/was-vm-ev...

Or Exokernels: http://pdos.csail.mit.edu/exo.html

Because why not:

https://groups.google.com/forum/#!msg/alt.folklore.computers...

ACM Fellow for Reinventing Virtual Machines: https://groups.google.com/forum/#!topic/alt.folklore.compute...

> ACM Fellow for Reinventing Virtual Machines

It was less "reinvention" and more "making them actually useful." From the ACM announcement[1]:

Although the concept of virtualization was first explored in the 1960s in the context of mainframe computers, it languished until Mendel Rosenblum and his students at Stanford University rediscovered the idea as a simulation tool for new multiprocessor architectures.

It goes on to point out how they created a vibrant industry and research area around the technology and spurred a shift to virtual-machine-based architectures.

[1] http://awards.acm.org/award_winners/rosenblum_4094918.cfm

Eh, most of the fun of alt.folklore.computers is listening to a bunch of geeks who were there from the time CTSS seemed like a novel idea moan about how everything was done before, either by DEC in the 1970s or IBM in the 1960s (or 1950s!). Oh, and DEC, not Digital: The VAX was an abomination and command line technology peaked with TOPS-20, if not TOPS-10.

(Seriously. One of the people I quoted claimed elsewhere, without any hint of irony, that IBM invented personal computing by putting CP-40 on System/360 mainframes, to give everyone their own personal guest system on the shared hardware. Yes, and the Ancient Romans invented radio by reflecting sunlight with mirrors; after all, it's all EM radiation!)

Or processes. If your hypervisor is KVM, then your KVM + unikernel essentially is a Unix process running on the host, just using a rather complex API instead of syscalls.

This is encouraging. A path to the post-C, post-Linux world is starting to become clear.

Exactly. In my mind that's the best thing about these projects: the technical benefits are so amazing they might actually encourage people to look beyond the Linux-and-company systems stack.

(Although, to be fair, most people run a Linux dom0.)

What's weird and funny is the collapse in complexity this represents.

Linux, NT, BSD, and other modern kernels implement all kinds of complexity around user/group management, ACLs, security policies, file types and permissions, and so on.

If we're moving to unikernels and containers and similar, all that has been replaced with stupid simple access control systems like API access tokens or login/password pairs for cloud service control panels. Your AWS access token is now a single security credential for your entire infrastructure.

Of course I'm sure the cycle of reincarnation will continue. Things like Docker or the AWS API will grow in complexity until they at least subsume the entire feature set of Unix UID/groups, Unix/NT ACLs, SELinux, etc.

I would argue that in a world where we've progressed past Linux and C, but still talk about using PHP, MySQL and Java, and other such middleware, including Ruby, Python, Perl and so forth, not much actual progress has been made after all.

It would simply feel like standing still, for an overhwelming majority.

To what end?

For those who are interested in this, you may also be interested in ZeroVM[1].

To be clear, ZeroVM isn't a Unikernel. Instead, it is a virtualization technology based on NaCL[2] that is designed to quickly create throw-away VMs. The idea is that the VMs is created to service a single request, and disposed of afterwards.

Obviously this model has challenges, but it is similar to the model proposed on slide 24 of the OP slidedeck. The security benefits of this are real, even if the programming model is challenging.

[1] http://www.zerovm.org/

[2] http://en.wikipedia.org/wiki/Google_Native_Client

Are there any benchmark comparing speed of execution of a xen+unikernel app vs no virtualization at all ?

I wonder if this tech would let you have bare metal speed in a cloud environment.

I love the idea, always have. Does a unikernel application need statically allocated amount of RAM or is there a way to have unikernel-programs allocate memory dynamically?

Maybe this is where garbage-collected language would be useful.

Seems to me a unikernel app would have access to all the RAM in the system. It is, after all, the kernel itself.

Yea but the hypervisor has to know how much physical memory to give the unikernel.

The way it usually works is that the guest OS gets a certain allocation of RAM and if it doesn't want to use it all it can inform the hypervisor of which ranges don't need physical backing at the moment. From the guest's perspective this is often implemented using a "balloon" process/driver that reserves a large chunk of guest memory in order to return it to the hypervisor. It can also be handled by the guest having a more general memory hotplug capability.

Look at a live version of Erlang on Xen.

http://erlangonxen.org/

Press ESC on the front page and see the amount of GC ram reclaimed from Erlang's VM.

Memory Usage: 12MB -- is also kind of a baffling number.

I was happy to see Clive, and I imagine a RUMP implementation or other unikernel that supports Rust won't be far away. Being able to compile Go or Rust to metal byte code is absurdly sexy.

I don't know how AWS will meter it yet (yup, I love AWS) but I sure hope they're following this trend. AWS support would put so much energy behind this path forward.

Isn't AWS built on XEN? I think the MirageOS folks have said you could deploy one of their unikernel apps on AWS as-is.

Yes it is, and AWS already supports unikernels.

unfortunately other providers, like DigitalOcean, don't seem to support rumpkernels or unikernels.

I believe the problem isn't so much that DO, etc., don't support unikernels, as that they use something other than Xen as the virtualization layer; something-other-than-Xen is still on the to-do list of the unikernel projects.

The rump kernel unikernel (rumprun) will happily work on actual hardware. It's a bit hazy if that's a unikernel or an embedded system in that case (and what's the difference anyway?), but to avoid hairsplitting, you can replace the hardware with KVM and off you go.

Yes, we can confirm that. We let you generate and run unikernels for JVM apps on AWS at https://boxfuse.com

Disclaimer: I am the founder

Interesting. Is it open source?

No. It is SaaS with an installable client. But we do have a free tier that is perfectly aligned to the AWS free tier. Also there is no lock-in per se as you give Boxfuse an app in a standard format (.jar/.war) and Boxfuse turns it into an image in a cloud native format like an AMI for AWS. All this with just a single command.

Any chance you'll support Rust or Go in the future? Our company doesn't deal with the JVM at all - mostly Python and Go currently.

Yeah, like Erlang on Xen... it's ready to deploy to AWS

http://erlangonxen.org/try/ec2

Reply on news.ycombinator.com