Can someone give me real life examples of unikernels being usefull in a vps/webhosting kind of scenario?


#1

HI

I am the ceo of a small cloud startup, I have been researching unikernels and find them fascinating,

Can some people give me some examples of how to implement them in a way that would have us benefit the most from them?

Also, most people use kvm with openstack nowadays, would you guys say xen is a better choice? In respect to unikernels I know it probably is, but what about the rest, is development still as good as the kvm dev. Is?

We got 12 big nodes with high end low latency hardware, and do like some of the features that are planned for xen 4.7, also, people told me that unikernels will benefit greatly from the real time schedular and the fact that you can have so much control over l3 cache, and do code prioritization,

Now we dont have any real ocaml or haskell/erlang developers, will this become a big problem? Will we need true specialists in one of these languages to make proper use of unikernels?

Hope to hear something soon,


#2

There are others here that can answer the technical issues much more thoroughly than I, but let me at least answer your last question:

It depends on the unikernel base you intend to use, but, in general, “No”. If you don’t have Haskell, Ocaml, and Erlang skills, you might not want to focus on HaLVM, MirageOS, or LING. But there are other choices (rumprun probably leading the list) which allow the use of more popular languages. I’d suggest starting there (unless someone more knowledgeable than I has a better recommendation).

Also, I’d expect Xen Project 4.7 to better serve unikernel workloads than most other platforms right now. Because of the origins of much unikernel work, Xen Project has had a greater awareness of the nature and the growth of the unikernel movement. There have been conscious efforts to make the hypervisor perform well with unikernel workloads. I hope that future releases will continue to make advances in that direction.

Russ (former Evangelist for Xen Project and unikernel bigmouth)


#3

Hi @cloudbuilder, I just thought I’d mention that IncludeOS is written in C++ for hardware virtualization and runs well on KVM, virtualbox and also OpenStack. We’re still early stage but we’re now developing our first web application with a RESTful API on top of it and it’s behaving pretty well :slight_smile: If you’re interested feel free to drop me a line or join us on gitter and we’ll help you get it up and running.


#4

Hi,
Refer to http://unikernel.org/projects/
You need to decide what kind of OS you need. Then you need atleast one person who understands well about the language, OS and how to use it, debug.
Unikernels are evolving and shows early insights about future OS for applications.

Let me know if you need further info.

Subbu


#5

Hi. Slightly late reply, but hopefully still relevant.

I can tell you a bit about where IncludeOS is currently going and that might give you some sense of possible applications for Unikernels.

For us unikernels can result in very fast (no context switches, small code base that fits in CPU cache), very secure (no syscalls, small attack surface) and very small images. This makes it perfect to implement internet appliances that do common tasks like load balancing, routers, firewalls, DNS serving and other household chores.

They are also very well understood tasks. Everyone knows what a load balancer or recursing DNS server should do and they are generally useful. So, our first commercial project is to replace a bunch of F5 load balancers with IncludeOS instances. We don’t have the extreme feature set that F5s have - but for 95% of the deployments out there these features are not needed - so to some extent it is a bit like a classic disruptive scenario.

Longer term we’re likely go after high performance JSON APIs (~ReST). That will likely be a bit of a harder sell as there aren’t that many C/C++ JSON APIs. For IncludeOS porting other runtimes is within what we can do. Both Node and Golang have runtimes that we can make sense of. But other runtimes are quite a bit into the future and we want to make the case for native C/C++ applications first.