Don't you think so, do you? Appropriate functionality is already implemented in host OS and in cloud stack, so what's the reason to add complexity for each VM? Cloud is a new kind of server, the platform for applications with its own specific, and it would be wise to leverage the advantages and write new, cloud apps. That approach is already here: http://www.openmirage.org/http://erlangonxen.org/
You see, we don't try to avoid OS-level completely. We want to avoid duplication of functionality inside each VM and unnecessary deployment and configuration efforts. That's what Erlang On Xen about.
That would be KVM or lxc way, which also possible:)
In our humble opinion Xen has better potential to be a node-level hypervisor for large cloud platforms. It already is, in Amazon, Rackspace, etc., actually, Xen is the standard hypervisor for public clouds. Of course, to be able to run instances in Amazon, we had to start from Xen.
Moreover, when you running Xen you don't need to consider Linux-specific process scheduler and memory management, thus there's no need to give up the control on very important things. Migration things from Linux within is also problematic, Xen gives that functionality for no additional cost. In short, there were reasons to choose Xen.
Isn't this just adding a ton of boilerplate code though?
It's in the cloud so you'll always need networking support, and that's going to be TCP/IP generally. You'll need to write files, so you also need a network file system or real file system driver of some sort, and a way to write to block device like objects.
Well, it's not so scary as it may look. Files are accessible through 9p protocol, both servers and clients of which could be implemented very easily. Again, in modern applications we often don't need access to a local file system at all, just to remote database. TCP/IP is implemented inside VM, it's not a problem, and if physical host has a TCP/IP offload card it can be imported from Dom0 through 9p with almost no cost at all. Recently we implemented concurrent block device driver and rudimentary filesystem over it to be able to run local databases, if required. I'm talking about much simpler implementation than you could meet in Linux or Windows, which are more than enough to provide some practical functionality. There is no need to put all complex things inside single VM, you can use remote services instead, and it's really useful now.
Whole "OS-less" and "elastic cloud" stuff sounds like marketing bullshit just because they were supposed to sound like that. And that's it, taking useless shit out is being created the new platform. Aside of fast start Zerg gives an imagination about how resources can be managed in cloud if we use lightweight, mobile VMs, this approach is quite different from traditional one.
Actually, you can save hundreds of hours of hard work of administrators who have to deploy and maintenance monstrous distributed applications. Erlang On Xen is not about throwing you on bare iron and not a glimpse back to 70s, development for this platform is not different from writing Erlang code for Erlang's standard environment. Erlang On Xen is deployment platform, that sets proper isolation of application code and enables efficietnt re-use of OS-related functionality that already implemented in hypervisor, Dom0 and in cloud services.
If you'd like proper resource usage, go to http://erlangonxen.org/ and press Esc (or click upper right corner of page). There are few hundreds users on site right now;)
That's correct. Erlang On Xen is all about proper usage of OS-related functionality already presented by hypervisor, Dom 0 operating system, cloud stack, third-party services in the cloud.
There's no need to use direct calls. All required functionality is already presented in hypervisor, Dom0 OS and cloud stack, Erlang On Xen just uses it properly without doubling the same in every VM.
Well, our approach means that you still have Linux in Dom0. But there is no need to run separate OSes in every VM, unless you run legacy software in it. Erlang on Xen is supposed to be a platform for _new_ applications.
Surely, pidgin English has some charm. And it certainly adds a good weight to the arguments, opponent suddenly feels that he could be eaten if he sounds lame...
Well, I would use "spreaded OS":) Of course, all OS-related functionality remains, but it's being orchestrated in a completely different manner. Different parts of appropriate functionality can be provided by another instances, hypervisor, Dom0 OS or even cloud stack. That approach gives us a loads of advantages - better resource granularity, fast start and fast migration, small and secure instances, much more resilient app code (since instances can be restarted after crash in a very short time), etc
Boot time is not the only issue. We have to confess that we do not need the fully-functional kernel in userspace in every VM we start in cloud. OS functionality can be redistributed over other instances and cloud stack services, such architecture provides much better flexibility and scalability than unnecessary doubling gigabytes of code and functionality in VMs.
Yes, we did. Actually, I've just mentioned it in the comment above. Cloud is our computer and VMs are our processes.
Saving the boot time is just an aspect of much bigger impact, think about simplified deployment and maintenance, better resource isolation and granularity, easier migration, much better security (yes, there's no shell inside), etc.
There are similar projects for OCaml (http://openmirage.org/) and Haskell http://corp.galois.com/halvm as well as some dull activity with Java VM in the same direction.
I believe, that this approach is the future, since it simplifies (a lot) building and management of elastic cloud-based applications.
I have to insist that there is no "traditional OS" inside VM in this case. Of course, all appropriate functionality exists, but components are being orchestrated not in traditional way. In modern cloud environments there's no reason to make all this unnecessary fuss with multiple layers of virtualisation - we need it only to run legacy code. Cloud is our next computer, and VMs are our processes which we run there. Why keep full functional kernel inside VM and play with context switches (for example) on virtual CPU? Instead of that we could outsource some parts to external instances, and make life a bit easier, it's what Erlang On Xen about...
This demo was prepared in less than a week, so there was a reason to use something well-known and simple to use, like libvirt. Production code will use Xen API directly, or appropriate cloud stack functionality.
Slashdot Mirror
Don't you think so, do you? Appropriate functionality is already implemented in host OS and in cloud stack, so what's the reason to add complexity for each VM? Cloud is a new kind of server, the platform for applications with its own specific, and it would be wise to leverage the advantages and write new, cloud apps. That approach is already here: http://www.openmirage.org/ http://erlangonxen.org/
You're right, evolution usually goes spirals. But I have to confess, it's quite exciting to be at the start of the next wreath.
You see, we don't try to avoid OS-level completely. We want to avoid duplication of functionality inside each VM and unnecessary deployment and configuration efforts. That's what Erlang On Xen about.
Thanks, you've got the point precisely.
That would be KVM or lxc way, which also possible :)
In our humble opinion Xen has better potential to be a node-level hypervisor for large cloud platforms. It already is, in Amazon, Rackspace, etc., actually, Xen is the standard hypervisor for public clouds. Of course, to be able to run instances in Amazon, we had to start from Xen.
Moreover, when you running Xen you don't need to consider Linux-specific process scheduler and memory management, thus there's no need to give up the control on very important things. Migration things from Linux within is also problematic, Xen gives that functionality for no additional cost. In short, there were reasons to choose Xen.
Isn't this just adding a ton of boilerplate code though?
It's in the cloud so you'll always need networking support, and that's going to be TCP/IP generally. You'll need to write files, so you also need a network file system or real file system driver of some sort, and a way to write to block device like objects.
Well, it's not so scary as it may look. Files are accessible through 9p protocol, both servers and clients of which could be implemented very easily. Again, in modern applications we often don't need access to a local file system at all, just to remote database. TCP/IP is implemented inside VM, it's not a problem, and if physical host has a TCP/IP offload card it can be imported from Dom0 through 9p with almost no cost at all. Recently we implemented concurrent block device driver and rudimentary filesystem over it to be able to run local databases, if required. I'm talking about much simpler implementation than you could meet in Linux or Windows, which are more than enough to provide some practical functionality. There is no need to put all complex things inside single VM, you can use remote services instead, and it's really useful now.
Whole "OS-less" and "elastic cloud" stuff sounds like marketing bullshit just because they were supposed to sound like that. And that's it, taking useless shit out is being created the new platform. Aside of fast start Zerg gives an imagination about how resources can be managed in cloud if we use lightweight, mobile VMs, this approach is quite different from traditional one.
Yes, but spreaded over the cloud.
Actually, you can save hundreds of hours of hard work of administrators who have to deploy and maintenance monstrous distributed applications. Erlang On Xen is not about throwing you on bare iron and not a glimpse back to 70s, development for this platform is not different from writing Erlang code for Erlang's standard environment. Erlang On Xen is deployment platform, that sets proper isolation of application code and enables efficietnt re-use of OS-related functionality that already implemented in hypervisor, Dom0 and in cloud services.
If you'd like proper resource usage, go to http://erlangonxen.org/ and press Esc (or click upper right corner of page). There are few hundreds users on site right now ;)
One of these days such systems will appear. I hope we made a step in right direction towards that future.
That's correct. Erlang On Xen is all about proper usage of OS-related functionality already presented by hypervisor, Dom 0 operating system, cloud stack, third-party services in the cloud.
There's no need to use direct calls. All required functionality is already presented in hypervisor, Dom0 OS and cloud stack, Erlang On Xen just uses it properly without doubling the same in every VM.
Well, our approach means that you still have Linux in Dom0. But there is no need to run separate OSes in every VM, unless you run legacy software in it. Erlang on Xen is supposed to be a platform for _new_ applications.
Surely, pidgin English has some charm. And it certainly adds a good weight to the arguments, opponent suddenly feels that he could be eaten if he sounds lame...
Well, and COLOSSUS' OS was an operator... ;)
Well, I would use "spreaded OS" :) Of course, all OS-related functionality remains, but it's being orchestrated in a completely different manner. Different parts of appropriate functionality can be provided by another instances, hypervisor, Dom0 OS or even cloud stack. That approach gives us a loads of advantages - better resource granularity, fast start and fast migration, small and secure instances, much more resilient app code (since instances can be restarted after crash in a very short time), etc
Boot time is not the only issue. We have to confess that we do not need the fully-functional kernel in userspace in every VM we start in cloud. OS functionality can be redistributed over other instances and cloud stack services, such architecture provides much better flexibility and scalability than unnecessary doubling gigabytes of code and functionality in VMs.
Yes, we did. Actually, I've just mentioned it in the comment above. Cloud is our computer and VMs are our processes. Saving the boot time is just an aspect of much bigger impact, think about simplified deployment and maintenance, better resource isolation and granularity, easier migration, much better security (yes, there's no shell inside), etc.
There are similar projects for OCaml (http://openmirage.org/) and Haskell http://corp.galois.com/halvm as well as some dull activity with Java VM in the same direction. I believe, that this approach is the future, since it simplifies (a lot) building and management of elastic cloud-based applications.
I have to insist that there is no "traditional OS" inside VM in this case. Of course, all appropriate functionality exists, but components are being orchestrated not in traditional way. In modern cloud environments there's no reason to make all this unnecessary fuss with multiple layers of virtualisation - we need it only to run legacy code. Cloud is our next computer, and VMs are our processes which we run there. Why keep full functional kernel inside VM and play with context switches (for example) on virtual CPU? Instead of that we could outsource some parts to external instances, and make life a bit easier, it's what Erlang On Xen about...
This demo was prepared in less than a week, so there was a reason to use something well-known and simple to use, like libvirt. Production code will use Xen API directly, or appropriate cloud stack functionality.