Live data from Hacker News

Atmanos: Build Go programs that run directly on the Xen hypervisor

github.com

41–50 of 56 posts

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#41

Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.

Brenden Gregg also has a great post on unikernel models: http://www.brendangregg.com/blog/2016-01-27/unikernel-profil... 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…

Are you still using LING? The project looks like it died.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#43
post #17

Earlier quoted context omitted.

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.

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

Where people seem to really care about perf is networking. What that means in non-crazy land is you cut out the kernel from that part, do networking in userspace, and pin a thread to a CPU to poll for packets. Like it's all MMIO and DMA anyway so ring 0 doesn't have to get involved if it doesn't want to. Then for other stuff you have convenient slow OS facilities. Including threads, processes, and disk I/O! Luxurious.

So it's not just that this has to perform better than a kernel, it has to perform better than not involving the kernel in the critical path, and it has to perform so much better that it's worth wanting to beat yourself in the face with a hammer after trying to diagnose the latest lockup. Unikernels are interesting to me, but like the demoscene or a semi tractor doing wheelies. Not for production usage.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#44

Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.

He has no choice but to say that as it is a threat for his business.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#45

Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.

Brenden Gregg also has a great post on unikernel models: http://www.brendangregg.com/blog/2016-01-27/unikernel-profil... 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…

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

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#46

Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.

I wonder what Bryan would think of the idea of the „unikernel“ designed from the get-go with DTrace and kdb hooks?

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#47
post #38

Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.

Yup, If you're running unikernels in a VM for "improved performance" you're doing it wrong. Containers are a much better solution. Unfortunately people see containers now as a packaging mechanism rather than an alternative to hardware virtualization. Also doesn't help that everyone runs their applications in The Cloud where you're required to run on a VM. I'd really like to see containers services like Joyent's take…

I'd really like to see containers services like Joyent's take off.

Same here, especially since the zones that the Joyent containers are built on are really easy to use and provide entire miniature yet full fledged UNIX servers, not to mention it’s all open source and gratis and the community is really competent.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#48
post #29

Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.

He has a horse on the race, of course unikernels are unfit according to him.

Apart from disassembling the machine code, assuming one could even attach a debugger to such an application, how would you debug a unikernel application in production?

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#49

Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.

He has no choice but to say that as it is a threat for his business.

How are theoretical applications which are designed to do just one specific thing a threat to a fully featured hypervisor with 15000 packages used in production?

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#50
post #48
post #29

Earlier quoted context omitted.

He has a horse on the race, of course unikernels are unfit according to him.

Apart from disassembling the machine code, assuming one could even attach a debugger to such an application, how would you debug a unikernel application in production?

Just like debugging Java and .NET applications running bare metal on production.

By having a rich runtime (kernel) that exposes the internals to the world, like Mission Control, TraceViewer and the respective debuggers, when the right set of flags/authentication are enabled.

Unikernel are no different from running embedded applications, bare metal.

Post reply on HN