
Atmanos: Build Go programs that run directly on the Xen hypervisor - loppers92
https://github.com/atmanos/atmanos
======
Timothycquinn
Bryan Cantrill has a great post on unikernel models:
[https://www.joyent.com/blog/unikernels-are-unfit-for-
product...](https://www.joyent.com/blog/unikernels-are-unfit-for-production)

From my read, the benefits do not outweigh the costs. If you want light weight
microservices, OS level virtualization is the way to go.

~~~
im_down_w_otp
Brenden Gregg also has a great post on unikernel models:
[http://www.brendangregg.com/blog/2016-01-27/unikernel-
profil...](http://www.brendangregg.com/blog/2016-01-27/unikernel-profiling-
from-dom0.html)

From my read, it counters Bryan Cantrill's claim that, "unikernels are
undebuggable".

From personal experience I'm also quite certain Bryan Cantrill's claim is
spurious in that regard, as I've used both debugging and tracing facilities w/
LING unikernels to assess a number of runtime and clustering issues.

~~~
dnautics
Ling is a special beast since erlang is basically begging to be it's own
runtime os.

~~~
pjmlp
A language runtime is an OS, when running bare metal.

That is how we used to program many 8 and 16 bit applications, and how many
keep programming embedded systems nowadays.

------
VirtualAirwaves
We've been running Erlang directly on Xen with "no os" for a while. Works
great and very efficient.

~~~
pmarreck
I have always been fascinated by this combo. Can you discuss your use-cases
and wins using this stack?

~~~
diwu1989
might be this or something similar,
[http://erlangonxen.org/](http://erlangonxen.org/)

~~~
pmarreck
no, I know that's what he's referring to, but I wanted to know how s/he was
actually _using_ it in practice, for a real-world task

------
StudentStuff
This is quite interesting, are there major performance benefits to using
something like AtmanOS? My main concern is if something like this will ever be
able to run bare metal, and cut out the overhead of a hypervisor, if
performance is critical, then a dedicated box is likely.

Then again, this brings us to the same issues that the *BSD and Darwin kernels
have, with really lackluster driver availability. While some big corps like
Sony might get AMD to build them a performant GPU driver, the tragedy of the
commons situation repeatedly occurs with BSD licensed projects, major
improvements aren't contributed upstream reliably as there is no business
reason.

~~~
jsiepkes
Well performance aside there is also the benefit of not having to maintaining
userland.

~~~
md_
What are the overheads of maintaining userland?

Not trying to be stupid, but I'm not really clear on what the advantage is of
this system. Do I understand correctly that the dom0 OS is still providing
drivers and hardware abstraction? So both that and _some_ userland exists
somewhere in the stack; it's just not duplicated in the virtualized OSes?

Is the main goal simplicity, performance, or something else?

~~~
jsiepkes
Userland isn't duplicated, it's 2 totally separated userlands. The userlands
may be the same distro in case of Xen (for example RHEL 7) but they still lead
separate lives; They are different installations. So that's also multiple
userlands in which you have to for example deploy patches (RPM's, Deb's, etc.)
for your SSH install.

~~~
md_
Yes, that's what I meant by "duplicated." :)

And yes, I see some value in the reduction of maintenance costs, but you're
not doing this manually--you have a package manager of some sort and you're
automatically tracking some standard image (either for your company or from
some upstream maintainer like Canonical). So conceptually I get the simplicity
argument, but practically speaking, it's not really more work to maintain two
userlands vs one, right?

I guess there's also an argument of resource (disk, memory footprint, etc)
overhead of the second userland. It's not clear to me how significant that is,
which was part of my question.

------
hamandcheese
I’d be interested to see performance comaprisons between this and Go on a
Linux variant.

Aside from performance, what are the alleged benefits of a unikernel?
Security?

~~~
yahoo234
I agree. The performance difference is critical.

Other wise - just have a slimmed down OS with ACLs.

Is anyone running JVM on a slim OS?
[http://unikernel.org/projects/](http://unikernel.org/projects/) seems to have
quite a list OSv ? mirageOS?

~~~
masklinn
Squawk[0] ran pretty much directly on the hardware, Sun had a JVM-on-Xen
project, OSv provides a lightweight pseudo-OS (not unlike rump kernels it
looks) which support JVMs. Possibly one step down, Oracle has a JRockit VE
edition which runs directly on the Oracle Hypervisor, but despite being Xen-
based it's unclear whether that can run on raw hardware.

[0]
[https://en.wikipedia.org/wiki/Squawk_virtual_machine](https://en.wikipedia.org/wiki/Squawk_virtual_machine)

------
acidtrucks
We're returning to the days of booting directly to you application, like we
did with apple II

------
liuw
Somewhat related: for anyone who is interested in unikernel development, there
is a new proposed project called Unicore under the Xen Project umbrella.

That project aims to reduce the effort for porting applications to run in
unikernels on different platforms (Xen, KVM and baremetal).

[https://lists.xen.org/archives/html/xen-
devel/2017-09/msg036...](https://lists.xen.org/archives/html/xen-
devel/2017-09/msg03680.html)

------
rlonstein
Nice. I immediately though of [https://mirage.io/](https://mirage.io/) and
[http://erlangonxen.org/](http://erlangonxen.org/) but with a more
"mainstream" language.

------
fiokoden
How can any performance gain match the benefits of running on a tuned SMP
kernel?

What exactly happens with SMP with this sort of application?

~~~
baruch
You either run it on a single CPU or the "os" layer needs to provide for
thread migration. It also obviously needs to provide thread scheduling.

~~~
fiokoden
Which is to say, DIY symmetric multiprocessing, or BYO kernel code in-
application.

I'd have to read a compelling technical explanation before believing this
could perform better than a Linux or BSD kernel.

In most cases, the Go code is going to be single CPU, and that ain't the way
the world works anymore. There's going to be a bunch of wasted computing power
on that VM

~~~
farazbabar
You can bind processing for a consistent subset of requests to an individual
cpu core - essentially sharding requests across cpu cores and benefitting from
very high l1 and l2 cache utilization. The idea is to treat the system with
multiple cores as bunch of single cpu nodes connected via bus instead of
network and without the unnecessary overhead of thread and process related
context swtiching.

~~~
fiokoden
And now you're implementing SMP in application. Zero chance of doing that as
well as the Linux or bsd kernel.

~~~
yazaddaruvala
Why? You're assuming there is no sharable code.

Instead of sharing the code at runtime, i.e. what an OS does. You could easily
share code at compile time, i.e. statically link a library.

Because of sharable code, "implementing * in application" should always be at-
least as performant as the best generic implementation (i.e. the
implementation you find in a general purpose OS). However, when appropriate,
customizing the implementation for the application would allow it to become
even more performant.

------
FrodeF
is this something like includeos
[http://www.includeos.org/](http://www.includeos.org/)

