Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Truly elastic clouds with Zerg: OS-less Erlang on Xen

zerg.erlangonxen.org

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#41

Post by e12e »

rwmj wrote: post #20
edwintorok wrote: post #18

Earlier quoted context omitted.

Agreed, if you are in control of the host OS then you might as well just run some unprivileged processes in some lightweight containers (LXC, or just user/network namespaces + chroot). There are two situations where running applications directly on the hypervisor might be beneficial though: - If you have to run multiple untrusted (and possibly malicious) tasks on same host. In this case virtualization provides better…

For the first case, I'd rather use something like Google Native Client. The attack surface of a VM is rather large, particularly when you consider the dozens of emulated devices and instructions. For example, there was a notable hole in SCSI emulation recently discovered which let any guest overwrite any part of a host's disk (by sending some obscure SCSI commands which weren't being filtered by the virtualized devic…

> For the first case, I'd rather use something like Google Native Client.

Wait, you're saying Google NaCl could be going the way of Java -- being used for server side containers, rather than client side apps? (I don't really see why you'd want that over using a single process(tree)/binary compiled from go...).

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#42

Post by mwcampbell »

How is Xen better in this context than a general-purpose OS kernel, be it Linux, BSD, or Illumos?

For a "truly elastic cloud", what one really needs is a homogeneous pool of host machines on which heterogeneous workloads can be quickly started and stopped. For this, I believe a general-purpose OS kernel is better, even if one dispenses with the usual accompanying userland, because such a kernel is already equipped to run more workloads directly.

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#43

Post by e12e »

e12e wrote: post #41
rwmj wrote: post #20

Earlier quoted context omitted.

For the first case, I'd rather use something like Google Native Client. The attack surface of a VM is rather large, particularly when you consider the dozens of emulated devices and instructions. For example, there was a notable hole in SCSI emulation recently discovered which let any guest overwrite any part of a host's disk (by sending some obscure SCSI commands which weren't being filtered by the virtualized devic…

> For the first case, I'd rather use something like Google Native Client. Wait, you're saying Google NaCl could be going the way of Java -- being used for server side containers, rather than client side apps? (I don't really see why you'd want that over using a single process(tree)/binary compiled from go...).

Oh, I see. Zerovm[1,2] is built on top of NaCl, and does indeed appear to be a "javaosification" of NaCl -- with no bytecode, no dedicated language, but a sandbox/lockdown of native code.

[1] https://news.ycombinator.com/item?id=3746222 [2] http://zerovm.org

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#44

Post by continuations »

> 0.6 sec ago is when we received your request. Within this time we managed to create a new Xen instance, boot it, and run the application that rendered the page you are viewing. By the time you are done reading this, the instance will be gone.

So every time it receives a request it launches a new Xen instance, processes the request, sends a response, and then kill the Xen instance?

And all that takes 600ms just to process a single request?

Why would anyone want to do that when I could just have a persistent JVM running on Linux to process requests in under 10ms?

What's the point of this?

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#45

Post by derleth »

viktorsovietov wrote: post #22
akent wrote: post #4

"Over capacity" "The demo is limited to 16 concurrent instances and 2 libvirt connections. Due to these limitations we were unable to spawn a new instance to service your request. Please try again later." Um.

Sorry gentlemen, we had used libvirt and it set some limits. http://erlangonxen.org/blog/glimpse-truly-elastic

> Sorry gentlemen

And ladies.

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#46

Post by ithkuil »

continuations wrote: post #44

> 0.6 sec ago is when we received your request. Within this time we managed to create a new Xen instance, boot it, and run the application that rendered the page you are viewing. By the time you are done reading this, the instance will be gone. So every time it receives a request it launches a new Xen instance, processes the request, sends a response, and then kill the Xen instance? And all that takes 600ms just to p…

> What's the point of this?

to show that's possible.

There are certainly better use cases for that. From the top of my head:

1) Per user VM. The first request for a logged in user will spawn a VM and then all requests for her will be routed there

2) Fine grained elasticity control. Currently it's difficult to decide when to spawn new VMs, because it takes time to spawn a new one (and billing is computed hourly, but that's another issue), so it complicated to decide whether to pump up the steam or wait a little bit more. Having a sub-second startup time could help creating better elasticity controls.

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#47

Post by philsnow »

mwcampbell wrote: post #42

How is Xen better in this context than a general-purpose OS kernel, be it Linux, BSD, or Illumos? For a "truly elastic cloud", what one really needs is a homogeneous pool of host machines on which heterogeneous workloads can be quickly started and stopped. For this, I believe a general-purpose OS kernel is better, even if one dispenses with the usual accompanying userland, because such a kernel is already equipped to…

Why should the pool of host machines be homogeneous ? Just for ease of administration ?

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#48

Post by reeses »

smoyer wrote: post #30

Isn't this simply an acknowledgement that having an entire OS (at least in a traditional sense) is overkill? I remember a couple of attempts to make the JVM run on bare metal (JavaOS was one if I recall correctly) and I think that, to a lesser extent, ChromeOS, FirefoxOS and company are trying to eliminate some of the bloat that's occurred. The other day I spun up a CentOS6 server on a VM and it required a minimum of…

Very similar to how most projects start with,"Let's design the database model..."

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#49

Post by wiml »

jared314 wrote: post #7

It sounds like they exchanged one container, an OS managed process, for another one.

Yes. Everything old is new again, it seems. Many old OSes were VM hypervisors in today's parlance--- VM/370 comes to mind; several of the first Unix and other systems I got to play with were virtual machines running on IBM big iron--- and it was also reasonably common to run programs directly in the VM without a guest OS.

When I was in school, a common formalism for talking about operating system design was that they provided a virtual machine abstraction to each process. As time went on the "devices" looked less and less like actual hardware devices, so instead of having an emulated punchcard reader and emulated interrupts, you'd have a read(2) syscall. But that's a relatively unimportant detail.

And with paravirtualization the cycle continues: the abstraction the guest sees is no longer that of a bare metal machine, but one with an increasing number of syscall-like hypervisor calls...

Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen

#50

Post by zobzu »

viktorsovietov wrote: post #31
zobzu wrote: post #27

few questions: "how do get logs of everyone accessing the server?" "how do you debug the server itself when it fails?" "how do you audit the server if an attacker actually breaks in?" it seems to me that the app has to implement all that as with an exokernel, except, there's a single process running, yours To my understanding: compared to traditional vms, what you gain is speed and simplicity. compared to jails and c…

every instance can export its monitoring information as 9p virtual filesystem, which easily can be mounted from outside we debug server code in BEAM, Erlang on Xen is a deployment platform, if instance crashed we simply restart it. intruder has very few chances to find breaking in beneficial - there's no shell inside which gives only minimal chances to snatch control, instance simply will crash. also, having of no OS…

It mainly mean that instead of using a shell that runs /bin/sh and associated control commands (ls, cat, whatever), you've to bring your own shell code and call the functions yourself. I assume one would write such a loader in erlang that serves a webpage to query any content from the fs, database, etc.

Also, IPC seems to be mainly network based, which means latency. Some modern OS designs function with the same base ideas: managed runtime, small codebase, fully contained processes but use system-local IPC and thus, do have multi-processing (instead of multi-nodes, or in fact, in addition to multi-nodes).

Maybe some of those should be written in a web-friendly language and ship and httpd for adoption (so far they've not been adopted as the cost of rewriting apps > using archaic OSes)

Ideally I'd see an OS with:

- above characteristics (singularity, plan9 like)

- Simple, fast, efficient filesystem (i.e. with features and performance as good as popular databases) - so you don't need a database server

- clustered resources that are language-aware: filesystem (database), cpu, memory are networked resources, but you get control from the code about what is executed on the same local instance (ie same physical system) and what can be shipped to "any instance" - this brings true, full elasticity. (all this is also a little plan9-ish but not exactly)

Post reply on HN