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.
Re:A runtime system is an OS (Score:5, Funny)
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: (Score:2)
That could work if you're using virtual hardware. The interface can be maintained constantly for years, you don't have to worry about compatibility like in the Bad Old Days of making sure your word processing package supported your new printer.
I just fail to see the advantage. You're making things considerably more difficult for the application developers to shave a little of boot time? Even if a site gets slashdotted, the load spike isn't going to come instaintainously, so why do you need the ability to br
Re: (Score:2)
But that's the thing: there is no hardware. In a virtual system, the hardware is implemented in software.
On a physical platform, the lowest level operations are things like sending disk requests or pushing Ethernet frames, because it would be madness to implement a CPU instruction that reads a file by name from the filesystem.
On a virtual platform, that's not madness, but actually rather convenient. When the lowest le
Re: (Score:3)
Of course there's hardware. There's always hardware. Computer software runs on hardware. There isn't some magic Star Trek alien cloud of pure energy where it runs. It's chips and circuit boards.
Unless you are running applications directly on real actual hardware you have an OS. Just because you call the application isolation mechanism a "virtual machine running under a hypervisor" instead of a "program running under an operating system" doesn't mean they're fundamentally different things.
It's just a matter
Re: (Score:3, Funny)
So, the os then.
Re: (Score:3)
And not a hypervisor at that point, but just an OS executing applications. Oh how novel!
Comment removed (Score:5, Insightful)
Re: (Score:2)
"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."
You took the words right out of my mouth. First comment. Well done.
"stop using OSes"? (Score:5, Insightful)
Re: (Score:2)
I think this means no guest OS. You can argue about whether the Erlang runtime constitutes an OS of sorts, but in their example they are not booting a general purpose kernel. Presumably they could port this to run on bare metal instead of Xen, although the boot times for physical hardware would never be as good as starting a new Xen instance.
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).
Re: (Score:3)
And why would the Erlang OS not be a particularly good one? Erlang runs a large part of the worlds telecom, both landline and mobile, specifically because of its robustness and feature set. When even AT&T, Alcatel and Nokia have started using Erlang for example, instead of just Ericsson where it was first invented and implemented, it rather indicates that it's good at what it does.
Re: (Score:3)
So loading up just the code required for the application, rather than loading an entire general purpose kernel and userland on top of it...
Sounds like just running your app on a multiuser server in the traditional way, only with some level of sandboxing...
So instead of xen, just use a standard multiuser os, the user logs in, perhaps over ssh, and runs their app, and logs out when done.
As an added advantage, existing os already have the facilities to account for resources used on a per user basis.
Re: (Score:2)
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:5, Informative)
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: (Score:2, Informative)
BIOS is a OS as a OS is a input/output system... lol...
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
Re: (Score:2)
BIOS is not an OS, it's just a library. And in the PC, the BIOS also contains the boot loader code. Once it's done the POST, initialized the hardware and got the boot code into memory its job is over and it goes to bed. The BIOS is just a bunch of routines you can jump into via an interrupt. It's standardized, it's "convenient" (so long as you're not doing anything tricky, which will certainly require loading a stub since the BIOS doesn't do tricky things) and it's there. And nobody uses it after boot any m
Re: (Score:2)
A cat is a mammal. A dog is a mammal. Therefore, a cat is a dog, QED.
Re: (Score:2)
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.
While that's true, your game was probably limited to very strict definitions of what hardware it would work under. Change the hardware even a little and the game would refuse to load.
Even in the server market there's significant benefit in having drivers, memory, networking, etc. managed by an OS.
More correctly (Score:2)
What you meant to say was that the installed OS of your computer was not involved. The games you were booting from floppies provided their own OS, and it did not resemble the one you were accustomed to.
The BIOS is part of an operating system. Some older operating systems use the ROM BIOS for all of their I/O. Older PCs booted up in real mode [wikipedia.org] and could use the ROM BIOS without consequences. Newer machi
Re: (Score:2)
That would be called a bootloader.
Many OS-less plattforms have bootloaders.
The thing about them is, no matter what features the bootloader has, once it passes control, they are of no use to the loaded program (unless you do some adr jump magic... maybe).
Re: (Score:2)
Nope, they were floppies written in assembly. The idea was indeed to get rid of the OS to eliminate overhead so the game could achieve more with less. There was no DOS code on them at all.
Re: (Score:2)
The BIOS reads the disk and kick-starts the app. From there the compiled code is working directly with hardware registers - not an OS level abstraction.
Early graphics were like this because early OS ha
Re: (Score:2)
Re: (Score:2)
The definition of OS isn't "any program that manipulates a hardware register". The games I wrote only used instructions I personally wrote, and the game could not be used to provide services to other applications because it was a game, not an OS.
Re: (Score:2, Insightful)
Re:"stop using OSes"? (Score:5, Funny)
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.
Re: (Score:3)
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.
So... emacs?
Re: (Score:2)
So you're telling me there are no tubes in my computer? And the guy over at Geek Squad who charged me $190 to "replace some bad tubes" duped me?
Damn, I bet he didn't even clean the coils either.
Re: (Score:2)
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.
Yes, it is just a series of tubes. ;-)
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:A real server OS. (Score:5, Informative)
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. (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: (Score:2)
But that sort of thing fits well with TFA, where they say "look ma, no OS!" when they do have software acting like that
There are reasons why "no OS" is interesting, it does take a while for Linux to boot, I usually boot it in 20s on my virtual servers, making that 3s would actually allow me to save money. If they really were booting Linux, could process CPU intensive request by just buying an instance booting my OS and serving the request in 10s instead of 27s. But as someone said this can be compared with the not so novel approach called "applications".
So if you can boot Linux in 2 seconds, I'll agree that the annoucment i
Re: (Score:2)
Does Linux really take 20 seconds to boot on a VM?
My impression was Linux's boot time is mostly probing for hardware or waiting on slow devices to initialize. It seems like in a VM you could skip all that, and also would be ignoring all the usual daemons.
The OS-less approach seems absurd though, because at that point it's really just an application being run on a multi-user system. And we've been doing that since the 80s.
Re: (Score:2)
The OS-less approach seems absurd though, because at that point it's really just an application being run on a multi-user system. And we've been doing that since the 80s.
Its absurd because its not OSless at all. There is nothing magical about a hypervisor. Its just a bullshit term someone came up with the clarify they were talking about an operating system + tools set specifically aimed at running other operating systems normally designed to run on the bare metal themselves.
If you stop booting the more general use operating systems on top of the hyper-visors as you say you have not eliminated the OS you have just gone back to a simple OS lacking shared libraries (which
Re: (Score:2)
Does Linux really take 20 seconds to boot on a VM?
No sorry, it's 10 seconds to create and start a vanilla Ubuntu server install instance, of course that's when most of the disk is in cache. That 20 second was a couple of years ago, I should have run the tests again.
Re: (Score:2)
And by create I mean setup stuff with libvirt assign disks etc, not isntalling Ubuntu.. :-)
Re: (Score:2)
Depends on the kernel. If you run a generic, it's still going to do all the probing even if doing so is pointless. If you one compiled just for the VM (and incapable of running on physical hardware), then it'll boot in seconds. Generally it's easier to run a generic kernel and accept the slower init time and memory overhead.
Re: (Score:2)
Depends on the server. They tend to have things like SAS drives and hardware RAID5 controllers with cache that desktops don't usually get. The big difference is really in the business side: When you buy a server from IBM or Dell, it comes with a promise that the design is tested to the highest standards and a promise that the manufacturer will keep the spares in stock for at least the duration of your support contract. Because when your server's RAID card catches fire, you don't want to discover that model
Re: (Score:2)
They're called blades
Re: (Score:2)
Why not simply have a single instance of linux, and then multiple instances of erlang running under that linux kernel? What benefit does adding xen into the mix bring?
It seems that doing it the traditional way would be both faster and more efficient in terms of resource usage, as well as easier since it would work better with existing applications and languages.
Re:A real server OS. (Score:4, Funny)
Since a cloud is made of millions of tiny water particles (the virtual servers), and this condenses them all to a single body of water, I suggest we call this revolutionary new approach "pond" computing.
Re: (Score:3)
hope google's gnu/linux servers don't hear you and poof out of their magical existence
we've had true clustering operating systems since the 1960s, by the way
Foreign link to libvert, not Erlang-specific (Score:2)
libvert [libvirt.org] is what communicates to the virtualized instance, and is the actual OS abstraction that runs on top of Xen in this case.
If there's no OS, we code to the metal, and there's zero "elasticity" in terms of being able to pop your process into any available machine in the cloud.
Re: (Score:2)
and yeah, "libvirt". I've had my head in too much visualization stuff. I should be in bed. :-P
Re: (Score:2)
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: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: (Score:2)
Well, only theoretically possible. While Erlang may be a functional language (it's not quite a pure functional language, but from the point of view of how variables work we may consider it so), bugs in the Erlang virtual machine could still allow memory overwrites - at the end of the day, the bytecode interpreter will be written in an imperative language.
Re: (Score:2)
and is this is different from the same type of bugs (which the malware maker's and system crackers love) in other OS how?
Symbolics, Lisp Machines, RMS, GNU EMACS (Score:2)
.
You have to go old old school to see "bare-metal" LISP:
Lisp Machines [wikipedia.org] were also made by some other companies, but did not do as well commercially.
Richard Stallman also has a bit to say abo
Re: (Score:2)
I've often wondered why we never see bare-metal versions of things like LISP or Erlang
One reason is that there are just too many variations of hardware you would need to write code for. The nice thing about Xen (and other hypervisors) is that you only need to care one set of virtual devices. Sort of the same reason we have operating systems so that the applications do not need to handle stuff like file systems and network and stuff...
Re: (Score:2)
But *why*?
Why should VMs be processes, whats wrong with processes?
Instead of putting xen on your hardware and running each instance inside of xen, why not simply put linux (or any other os) on the hardware and run each instance as a process on linux?
Re: (Score:2)
Minimum != No (Score:2)
Sarcasm aside... there is something working as an OS it's just trimmed down to the bare minimum. Also, check your damn summaries.
Re: (Score:2)
Chrome is a virtual box too - NaCl (Score:2)
This seems to talk purely about virtual servers, not hardware. Everything above hardware is nothing but programs, even if we call them virtual PCs. They only differ in the level of integration with the rest of the machine and peripheral devices. For example, javascript running in a browser could be considered as much of a virtual pc as Oracle's VirtualBox, with the only difference being the interface with which internal code communicates with the outside. Chrome's native client (NaCl) ability to run native
Reusable OS-less instances (Score:3)
Oh, wait, I guess we just reinvented the process...
Re: (Score:2)
Hey, I know! I bet we could speed things up even more if each one of these reusable minimal-OS VM "processes" could do several things at once. We could call it, I don't know, maybe "threads" of execution.
Ethel! Call the patent office!
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: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.
Re: (Score:2)
What sort of thing would you actually use this for? How is it significantly better than just having a shared server running a bunch of applications?
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.
Re: (Score:2)
Re: (Score:3)
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.
The reality is that compartmentalization consumes resources of some kind or another, so we tend towards less of it. In theory a highly segregated system (e.g. microkernel) can be efficient, but in practice the monolithic systems seem to be where the power and scalability are for applications which are not embarrassingly parallelizable.
Re: (Score:2)
Maybe the merging of "vaguely related things" into "one giant monster" was the wrong choice... but only if you're looking back at it from the current reality of powerful hardware available at low cost. Back then, it was the right choice. A monolithic, fully pre-emptive, multitasking, virtual memory based operating system with a common application programming interface was the innovation that made ubiquitous computing possible.
Re: (Score:2)
Thanks! That was exactly the sort of answer I was looking for.
DOS (Score:5, Funny)
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.
Re: (Score:2)
I actually used to do some multitasking under DOS, running more than one of my own tasks at the same time. It all had to be coded by hand fooling around with the timer interrupt to do my own time slicing. TSR programs were in the picture too...
https://en.wikipedia.org/wiki/Terminate_and_Stay_Resident [wikipedia.org]
Re: (Score:3)
Look at Desqview: http://en.wikipedia.org/wiki/DESQview [wikipedia.org]
I used to run a BBS under it and it allowed me to run 3 - 4 instances of my software to offer multiple dial-in lines off the same PC.
For the life of me, I never understood why MS didn't buy them out and just incorporate it directly into DOS. It was stable and "just worked." I do realize the DOS was going to die either way, but Desqview rocked and would have been a great way for MS to end it on a positive note.
Re: (Score:2)
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: (Score:2)
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. At some level, all this is just "things a very minimal Linux kernel" would do for us.
That all said, I'm now very curious about how quickly said kernel would spin up and launch a custom application a
Virtualization is kind of bullshit (Score:2)
when you virtualize in unix system, then you create a virtual machine to run multiple applications seperated from each other on a OS, which was invented to run multiple applications seperated from each other. Many applications do not really need a VM, but just a shell account and some own ip, where they are allowed to use privileged ports.
other approaches are chroot/lxc/linux-vserver maybe openvz lightweight VMs.
Re: (Score:2)
-config files and adhoc installed libraries are impossible to link to the application that actually needs it (given the fact that my time is scarce). Nightmare when upgrading, creating new instances or when pulling apart a system (for e.g. performance/HA).
-if an application uses resources, e.g. I/O, too much you want to know about it, point fingers and restrict its usage (and maybe give it its own). Nightmare when you want to find out 'w
Re: (Score:2)
-config files and adhoc installed libraries are impossible to link to the application that actually needs it (given the fact that my time is scarce). Nightmare when upgrading, creating new instances or when pulling apart a system (for e.g. performance/HA).
chroot.
-if an application uses resources, e.g. I/O, too much you want to know about it, point fingers and restrict its usage (and maybe give it its own). Nightmare when you want to find out 'what causes it to grind to a halt during Xmas'.
iotop. A VM only makes this problem harder.
-applications has 'resources' they should not have, because another application needed that 'resources'. Example: Qmail needed compiler and afterwards a cracked PHPMyadmin used that to compile malware.
chroot with linux-vserver enforcement.
Re: (Score:2)
chroot
True. Issue is that what was once handily placed on one server, speaking year 2000 here, now needs to be torn apart. Things have history: Early developers are not always good at admin work. Too easy to get it wrong.
iotop. A VM only makes this problem harder.
We use iotop of course. It was an example of one of many resources: file descriptors, connections, memory, io, bandwidth, ... I agree that a VM can make things harder.
chroot with linux-vserver enforcement.
We use OpenVZ, at the moment.
Re: (Score:2)
and thats an argument, to boot a full kernel, just to seperate the access to gcc?
That just some "we have the ressources anyway" argument.
Re: (Score:2)
Xen's Mini-OS (Score:2)
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.
Re: (Score:3)
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.
The point is elasticity, being able to very rapidly scale in response to surges of demand. If you put this in production you wouldn't have it handle only a single request per VM instance, you'd probably have each instance stay up and continue handling requests until the incoming request rate dropped below some threshold. Because starting new instances is so inexpensive, though, you could set that rate pretty aggressively, then let the pool of active servers expand and contract dynamically (and very rapidly)
Re: (Score:2)
Okay, this all sounds awesome. I can see how it's not like a traditional operating system... it spawns servers dynamically in response to external requests, it must provide a way to control those servers while also facilitating (and mediating) their access to hardware, and I imagine that it probably has a way to receive and process internal commands that may alter how it is operating.
So how is it not an OS?
I thin the word we're looking for... (Score:2, Insightful)
...is HYPE,
Nothing to see here, move along
this is different from inetd how? (Score:2)
This seems like a really latent reimplementation of inetd.
Bogus summary (Score:2)
Rewind to 1975 (Score:2)
I have in front of me a Cambridge University Computer Science Tripos examination paper from June 1975. Question 7 reads:
"Computer operating systems are very complicated things whose purpose is to help people to share the use of equipment. They will become largely obsolete as the equipment becomes cheap enough not to need sharing". Discuss the prescience or wrongheadedness of this remark.
This was long before the personal computer which came along later and initially more or less dispensed with the tradi
Re: (Score:2)
But we have OS-less computer systems with human interfaces everywhere, from automobiles to microwave ovens to thermostats.
Ahhh, unfortunate word choice. (Score:2)
How is this different from Sandboxing? (Score:2)
From what I understand this is somewhat what many sandbox-based software does. For instance, it seems to me that if you installed Chrome on many servers and then, upon a request, deployed the code and used a Chrome sandbox to run and return the data the end result would be the same.
The challenges are still the same: how to deploy the code fast enough and how to route the request to the correct sandbox.
Re: (Score:2)
Well, the OS-less platform providing the linked document was only up for 1 second and is therefore off-line now...
Re: (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
Re: (Score:2)
"may change our understanding of how long does it take to bring a server up"
This sentence is writed by no-brains.
This sentence is written by no-brains
-The editor
Re: (Score:3)
Whoosh.
Re: (Score:2)
OK, but if the case, then something like:
Does this sentence is written by no-brains ?
Would have been more appropriate IMHO.
Bonus: Google for "writed" and you will find out more people than you may think use it.
Re: (Score:2)
Yep, nothing new, it's called a container, other implementations are FreeBSD jail, OpenVZ, Linux-Vserver or LXC.