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 runtime system is an OS (Score:5, Insightful)
If you don't need much from your OS, then trim the OS down. That doesn't mean you're not using an OS. Unless you run bare-metal code, you are using an OS.
"stop using OSes"? (Score:5, Insightful)
Still an OS... (Score:5, Insightful)
Instead of focusing on the irrelevant and incorrect "not using an OS", why not focus on the more interesting fact that for some tasks, it may be worth the effort to create a custom build of the OS with only the functions needed. That version may even be automatically created (or chosen) as part of the application build.
Re:A real server OS. (Score:4, Insightful)
Servers didn't use to be beefed-up desktops, no "still" about it. That they are now has to do with cheap desktop ubiquity and wanting to use desktop emulator software to underpin "servers". In short, middle management stupidity.
But that sort of thing fits well with TFA, where they say "look ma, no OS!" when they do have software acting like that, only not calling it that. Put the achievement in perspective and it isn't nearly as ground breaking as implied. So the announcement is a bit pompous. Well, nothing new there either.
It's all a bit bass ackwards, but then so is the whole peecee paradigm. The whole virtualisation thing has been with us for ages, in many guises. This is but yet another. Likewise, single-language app boxen. Lisp machine, anyone? Only this time with erlang.
On another note, rethinking how we organise monitors, supervisors, hypervisors, hardware drivers, and all that, and how they interact with userland, isn't a bad idea. This here idea is a valid approach, but by no means the only one.
Re:"stop using OSes"? (Score:5, Insightful)
You can argue about whether the Erlang runtime constitutes an OS of sorts
AFAICS there's no argument at all. It is an OS; not a particularly good one, but one that provides scheduling, interprocess communication (albeit for what we'd traditionally consider to be threads rather than processes, but due to Erlang's memory/threading model there's actually no real distinction), memory management, and abstraction of IO (albeit somewhat simplified from the approach taken by a typical modern OS).
Just another OS (Score:4, Insightful)
If you think about it, a hypervisor is just an OS that manages other (guest) OSes. It enforces privilege separation and abstracts device access to the guest OS.
If you replace the guest OS with a guest application ... it's really just a regular OS again. You know what else takes less than 1-2 seconds to start up and shut down? A UNIX process.
From a technical perspective, maybe there's some value in moving beyond the traditional *NIX APIs, filesystems, etc, and defining a novel, possibly simpler interface for running and managing application code.
Or go in the opposite direction by extending its capabilities, taking advantage of the new hypervisor security space to let app runtimes take over traditionally OS-level "ring 0" responsibility like page tables and interrupts/handlers with full hardware acceleration.
You can't call it OS-less though, unless you really mean "less OS" rather than "without an OS". Call it OS-minus, or maybe even OS-plus.
Re:Not quite OS-less, but still sounds neat (Score:4, Insightful)
I'm not clear on exactly what the difference is between a hypervisor+para-API and a normal OS.
None. The paravirtualisation API is pretty much identical to those provided by normal OSs, except that it is designed in such a way that other OSs can easily be rewritten to use it rather than raw hardware features. This pretty-much means that the only real difference is in terms of what kind of features it provides, rather than how it does it.
Awesome performance (Score:4, Insightful)
Upon reception of an HTTP request, the demo spawns a new Xen domain with LING VM and a web application written in Erlang. After serving a single request the domain simply shuts itself down and frees all resources. The whole process takes 1.5-2sec.
I think that 1 connect per 1.5-2 seconds minimum is probably impressive for a web server if its running on ... well hell, I don't know, an Arduino can serve pages faster than that.
Considering that Apache or IIS on any modern hardware, even limited to a single core will move 400 requests a second or more without breaking a sweat then I'm not really getting why I'm supposed to be impressed with their silly misuse of resources. This setup is more or less an example of why we have people who write OSes, people who write server software ... and guys like this who reinvent the wheel ... poorly.
I thin the word we're looking for... (Score:2, Insightful)
...is HYPE,
Nothing to see here, move along
Re:"stop using OSes"? (Score:4, Insightful)
No. That would be stretching the meaning of the word so far it becomes meaningless.
Re:"stop using OSes"? (Score:4, Insightful)
OS is specifically an Operating System
An OS is an abstraction written to provide an interface between applications and hardware. It is specifically designed to manage memory, disk, devices, and the loading/unloading of applications. It is typically refereed to in simple terms as the "traffic cop".
OS-less platform is relying on code to be compiled to interface directly with the hardware. There is no abstraction level. There are no C libraries that can be linked together, because there is no OS to link and load models.
You can get away with this "in the cloud" because there are no hardware interfaces that need to be directly accessed. There is simply memory management which the application will be responsible for, and some sort general IO.
You are essentially programming a virtual micro controller - which just happens to have a boat-load of memory space.
-CF
Comment removed (Score:2, Insightful)
Comment removed (Score:5, Insightful)