A Glimpse of a Truly Elastic Cloud 201
New submitter cloudozer writes "Virtual servers in the future may stop using OSes entirely. As recently demonstrated OS-less platforms may change our understanding of how long does it take to bring a server up. A demo server gets created, booted up, configured, runs an application and shuts down in under 1 second. Radically lower startup latency means that the computing infrastructure may be woven strictly on demand, during the processing window allotted for a given request. Currently cloud providers round an instance uptime to the full hour when calculating charges. They might need to switch to per-second billing if OS-less instances get traction. The demo uses a new Erlang runtime system capable of running directly on Xen hypervisor."
A real server OS. (Score:5, Interesting)
This could be interesting. Servers are still designed like PCs. That's not fundamental. One could have compute servers which have network hardware that is configured during the boot process and which restricts what the machine can talk to. Their storage is all external, on file servers elsewhere. They have no peripherals other than the network. They barely need an operating system - the remote management hardware in the network interface handles administration.
With Linux at 15,000,000 lines of code, there's a bloat problem. There's still a need for a run-time library, but it will be more like the C run time system than an OS.
Re:Link? (Score:3, Interesting)
Does anybody else see the problem with this? One second to render a single page. Two thirds of it spent setting up a virtual machine, a quarter booting the Erlang runtime (the OS...) and then a couple of milliseconds to actually perform the work for which the instance was created.
Yes, you do not need a big OS to perform a trivial task, but on the other hand it doesn't take a long time to perform a trivial task, so even a very short boot time is prohibitively expensive compared to the actual task. This doesn't look like a sweet spot at all.
Not quite OS-less, but still sounds neat (Score:5, Interesting)
The broken link should probably point here [erlangonxen.org].
If I read the article right, they're using a hypervisor (Xen) to directly run an Erlang interpreter (LING VM) that they wrote. The interpreter relies on Xen to provide some higher-level functionality. (Wikipedia says this is called paravirtualization [wikipedia.org].) So it's not quite a web server running on bare (virtual) metal, cool as that would be.
It looks like the significance of this is twofold. First, people are using VMs to create run-time environments that are less featureful than a standard OS but much faster to start up. Second, there's a working demo of a simple virtualized web server using this concept. I don't really follow virtualization tech, so maybe someone can clarify this? I'm not clear on exactly what the difference is between a hypervisor+para-API and a normal OS.
Re:Still an OS... (Score:5, Interesting)
I just have to say, I'm not quite sure where Xen fits into the picture here. Why do we need it? Why not run something much simpler -- Erlang is a fully memory-safe language where it is impossible for one piece of code to modify the memory in use by another piece of code (because it is a pure functional language, and such operations are basically not possible in a pure functional language), so there is no necessity to protect instances from each other. So why, therefore, does their system not run on base hardware without the hypervisor, thus avoiding the extra abstraction layer?
Re:Not quite OS-less, but still sounds neat (Score:5, Interesting)
I'm not clear on exactly what the difference is between a hypervisor+para-API and a normal OS.
Essentially, traditional operating systems mix several vaguely related things into a single system:
1) The "core" of an operating system: resource management, device drivers, isolation, time sharing
2) Useful "libraries" or APIs: advanced networking features, security such as access control and authorization, filesystems, etc...
The reality is that the two should have been split from the beginning, not merged into one giant monster, because different applications need different things, and the rest is just a maintenance and security nightmare just because it's present in the kernel or in privileged system services.
For example, some databases like Oracle can directly format a block device and treat it as a "file" in the database. No operating filesystem required, that's just overhead. Similarly, cross platform products need to have a portable set of libraries (#2), but don't typically care about drivers and whatnot. Hence, many products ignore the built-in libraries of the operating system, and roll their own anyway, which means whatever is in the OS is just wasted.
What hypervisors bring to the table is that they correctly split out #1 and #2, each optimised for its own thing. The "core" becomes the hypervisor kernel, and "2" becomes the guest virtual machine's operating system. This is why well written hypervisors such as VMware ESXi tend to be crazy robust. They have one job to do, and they do it well. The problem is that the client virtual machines are still using legacy operating systems with both #1 and #2 instead of just #2, which is redundant. This Erlang project is a simplified OS that lets the hypervisor do its thing, and then only loads what Erlang needs inside the guest, and nothing else. Hence the fast startup times and I'm guessing good efficiency.
In this kind of split environment, the guest "OS" would typically run a single "application" per virtual machine, which is already typical anyway, but by making that assumption from the beginning, a bunch of simplifications can be made: everything can run in ring 0, there's no need for access control lists, serial ports, display drivers, or any of that junk. Just a basic filesystem, basic IP-only networking, and network-based security such as SAML or Kerberos.
Essentially, in an idealised hypervisor-based computing world, most code that's currently part of Linux or Windows would move into user-mode libraries that ship with compilers, and the "operating system" would be essentially a modern version of DOS: something trivial to start processes, then get out of the way.