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

21–30 of 59 posts

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

#21

Post by viktorsovietov »

jacques_chester wrote: post #2

Nifty. I postulated a while back that the virtual machine would eventually be the target of web application design[1]. I wrote an honours project proposal for a blog engine based on reckoning that if you can control a (virtual) machine from the bottom up, why stay trapped in the architectural constraints of shared hosting? At the time I referred to the Mirage project, which was an OCaml runtime ported to sit directly…

yes, very soon we will start to give attention to writing application over this platform. there is some work still needs to be done in management stack, but it's manageable amount of work.

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

#22

Post by viktorsovietov »

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

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

#23

Post by viktorsovietov »

jared314 wrote: post #7

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

When you sat in container, you're limited with libraries of host OS, and there still will be some issues with migration and resource management (on large scales)

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

#24

Post by viktorsovietov »

jlouis wrote: post #19
arb99 wrote: post #3

" 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. " for a basic page like that is a bit slow...

True, but the Erlang VM is not really written for fast startup. Module loading is serial and not parallel. The key here is that you can scale up in 0.6 seconds, which is awfully much faster than most other solutions, where scaling takes minutes.

BEAM ("official" Erlang VM) starts much longer. Erlang On Xen has it's own VM (written from scratch), it was designed for run without OS and to srtart very fast, particularly.

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

#25

Post by asadjb »

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.

I got the same response. But then I refreshed and it worked. Magic, no?

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

#26

Post by peteretep »

mmcnickle wrote: post #14
peteretep wrote: post #6

Earlier quoted context omitted.

Presumably the idea is that you run a pool of them, so you're not spawning a new instance each time?

I got the impression that you _are_ expected to spawn a new instance each time.

My impression is that the fast loadup is for scaling upwards as needed. I am only expecting it to spawn a new piece if I am the first person whose request can't be answered as part of a wave of unexpected traffic... Why else would you want this?

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

#27

Post by zobzu »

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 containers, what you gain is simplicity.

I wonder if it would not be better, to use an actual OS written with a modern language, so that we retain some of the useful attributes (multiprocessing, ie each "vm" is really just a container with a messaging system, unshared filesystems, but with some shared areas, etc.)

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

#29

Post by arb99 »

smosher wrote: post #16
arb99 wrote: post #3

" 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. " for a basic page like that is a bit slow...

Thanks for pointing it out, I gave me an excuse to look at the numbers: I took 4.6 seconds when I loaded it. In the breakdown ~4.3s of that was nginx dicking around (probably spending much of its time telling people it can't spawn an instance right now.) The lightweight nature of the page is obviously exposing the nginx overhead, which is turning out to be a bottleneck. Based on all that: with more complex pages, a m…

fair enough. was just pointing it out as it is presented as if it is fast for a page load time. neat project though.

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

#30

Post by smoyer »

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 512MB of RAM. I remember building RedHat5 system (not RHEL5) with 32MB or 64MB. What is the new server doing differently? Functionally I have the exact same machines (yes, the newer machine is more secure, but should that really require 8x the memory?).

So these micro-systems allow the user to go "back to DOS" if they think Windows is too overblown. And if you don't need a windowing system, and you have the language tools you need, why not treat the VMs (or hardware devices) as embedded systems.

Post reply on HN