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."

Comments

A runtime system is an OS

[Anonymous Coward]

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.

Re:A runtime system is an OS

[Anonymous Coward]

No kidding. Are we going to allow application programmers to start making direct calls to the hardware? If so, then kill me now. Use a spoon if you have to, it will be more merciful.

Re:A runtime system is an OS

[squiggleslash]

Even if you are hitting the bare metal, the 1970s and 1980s taught us that you still tend to have something called an OS around, even if it's just a program loader and some kind of defacto standard for storing files.

This is worse than those people who confuse a kernel with an operating system, forgetting why the word "kernel" was invented in the first place. The term operating system is an umbrella term for a massive range of concepts, ultimately boiling down to a set of tools or concepts that ensure a user can manage the applications and data on their computer. That could, in theory, be entirely codeless. In this instance, it's not, there's Xen, and some kind of virtual hardware layer.

"stop using OSes"?

[1u3hr]

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.

Re:"stop using OSes"?

[julesh]

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).

Re:"stop using OSes"?

[ls671]

Unless we're returning to the 1940s and wiring up tubes to make programs,

I had a few games on bootable floppies back in the original PC days, around 1985. The floppies would boot up the computer right into the game so there was no OS involved. And no, BIOS is not some kind of bisexual OS, it stands for Basic Input/Output System.

Re:"stop using OSes"?

[itsdapead]

No, no, no! It can't be an OS without a graphical user interface, web browser, email client, calendar, media player, typesetting system, at least three text editors, five or more programming languages, drivers for every peripheral known to man and a collection of games. Heck Apple's so-called "OS X" barely qualifies, lacking an integrated implementation of "Minesweeper".

Even with 'modular' operating systems, if enabling file sharing doesn't install Ghostscript and X11 then something is very wrong.

An OS without all these is like a text editor without Lisp and Eliza.

A real server OS.

[Animats]

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:A real server OS.

[AmiMoJo]

Linux scales insanely well. You can boot it from flash on an ARM based system in a couple of seconds. Intel demonstrated booting from cold to a graphical desktop in five seconds years ago.

Re:A real server OS.

[Let's All Be Chinese]

Servers are still designed like PCs.

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.

Still an OS...

[FaxeTheCat]

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.

Re:Still an OS...

[julesh]

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?

Not quite OS-less, but still sounds neat

[AdamHaun]

The broken link should probably point here.

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.) 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:Not quite OS-less, but still sounds neat

[bertok]

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.

DOS

[GbrDead]

Reminds me of a certain OS from the distant past. It had file system support, a process launcher (one process at a time), and... more or less, that was it.