Slashdot Mirror
A Glimpse of a Truly Elastic Cloud
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."
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.
What gibberish is this? There is an OS, presumably Xen. Unless we're returning to the 1940s and wiring up tubes to make programs, there is an OS.
So instead of booting a general purpose OS, the system uses one OS specifically for running other OSes (XEN) and one minimal special purpose OS for running the application (Erlang runtime). Whether you cal it a hypervisor or a runtime system, it is still an OS.
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.
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.
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.
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.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
...is HYPE,
Nothing to see here, move along
Tubby or not tubby. Fat is the question