Forgot your password?
typodupeerror
Cloud Operating Systems IT

A Glimpse of a Truly Elastic Cloud 201

Posted by timothy
from the nice-to-meet-you-goodbye dept.
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."
This discussion has been archived. No new comments can be posted.

A Glimpse of a Truly Elastic Cloud

Comments Filter:
  • by Anonymous Coward on Sunday March 24, 2013 @03:06AM (#43261617)

    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.

    • by Anonymous Coward on Sunday March 24, 2013 @04:32AM (#43261809)

      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.

      • 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

      • by vidnet (580068)

        Are we going to allow application programmers to start making direct calls to the hardware?

        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

        • by Ritchie70 (860516)

          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

    • by squiggleslash (241428) on Sunday March 24, 2013 @10:54AM (#43262937) Homepage Journal

      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.

    • "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)

    by 1u3hr (530656) on Sunday March 24, 2013 @03:12AM (#43261637)
    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.
    • by PTBarnum (233319)

      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.

      • by julesh (229690) on Sunday March 24, 2013 @04:27AM (#43261803)

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

        • by Shinobi (19308)

          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.

      • by Bert64 (520050)

        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.

    • There many applications that run without an "OS", sometimes even made to fit inside the CPU's cache, big advantage is that no OS overhead is involved, lots of dedicated console setups or micro controller software uses such configuration for example.
    • by ls671 (1122017) on Sunday March 24, 2013 @04:29AM (#43261805) Homepage

      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)

        by Yaa 101 (664725)

        BIOS is a OS as a OS is a input/output system... lol...

        • by ChronoFish (948067) on Sunday March 24, 2013 @09:21AM (#43262491) Journal
          No - BIOS is specifically a Basic Input Output System.
          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
        • by drinkypoo (153816)

          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

        • by femtobyte (710429)

          A cat is a mammal. A dog is a mammal. Therefore, a cat is a dog, QED.

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

      • You said; "The floppies would boot up the computer right into the game so there was no OS involved."

        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

    • by itsdapead (734413) on Sunday March 24, 2013 @08:11AM (#43262275)

      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.

      • 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?

    • by PopeRatzo (965947)

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

      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.

    • by rwyoder (759998)

      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)

    by Animats (122034) on Sunday March 24, 2013 @03:18AM (#43261659) Homepage

    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)

      by AmiMoJo (196126) * <mojo@NOspaM.world3.net> on Sunday March 24, 2013 @04:18AM (#43261785) Homepage

      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.

    • by Let's All Be Chinese (2654985) on Sunday March 24, 2013 @04:26AM (#43261801)

      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.

      • by emj (15659)

        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

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

          • by DarkOx (621550)

            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

          • by emj (15659)

            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.

            • by emj (15659)

              And by create I mean setup stuff with libvirt assign disks etc, not isntalling Ubuntu.. :-)

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

      • 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

    • by stevelinton (4044)

      They're called blades

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

    • and yeah, "libvirt". I've had my head in too much visualization stuff. I should be in bed. :-P

      • by vsov (2874465)
        This demo was prepared in less than a week, so there was a reason to use something well-known and simple to use, like libvirt. Production code will use Xen API directly, or appropriate cloud stack functionality.
  • Still an OS... (Score:5, Insightful)

    by FaxeTheCat (1394763) on Sunday March 24, 2013 @03:22AM (#43261669)
    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... (Score:5, Interesting)

      by julesh (229690) on Sunday March 24, 2013 @04:32AM (#43261811)

      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?

      • by Alioth (221270)

        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.

        • by rubycodez (864176)

          and is this is different from the same type of bugs (which the malware maker's and system crackers love) in other OS how?

  • 'OS-less' based system, sweet! Just think, we'll save a few seconds during the boot up process and it will only take hundreds of hours for our devs to code in assembly / binary! It's almost as efficient as the href-less anchor tag.

    Sarcasm aside... there is something working as an OS it's just trimmed down to the bare minimum. Also, check your damn summaries.
    • by vsov (2874465)
      Actually, you can save hundreds of hours of hard work of administrators who have to deploy and maintenance monstrous distributed applications. Erlang On Xen is not about throwing you on bare iron and not a glimpse back to 70s, development for this platform is not different from writing Erlang code for Erlang's standard environment. Erlang On Xen is deployment platform, that sets proper isolation of application code and enables efficietnt re-use of OS-related functionality that already implemented in hypervi
  • 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

  • by FaxeTheCat (1394763) on Sunday March 24, 2013 @03:40AM (#43261723)
    So to develop this further, we could create reusable OS-less (or minimal-OS VMs, if you prefer) instances to save the boot time.

    Oh, wait, I guess we just reinvented the process...
    • by Chelloveck (14643)

      So to develop this further, we could create reusable OS-less (or minimal-OS VMs, if you prefer) instances to save the boot time. Oh, wait, I guess we just reinvented the process...

      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!

  • by AdamHaun (43173) on Sunday March 24, 2013 @03:43AM (#43261733) Journal

    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.

    • by julesh (229690) on Sunday March 24, 2013 @04:40AM (#43261833)

      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.

    • by AmiMoJo (196126) *

      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?

    • by bertok (226922) on Sunday March 24, 2013 @05:12AM (#43261923)

      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.

      • by CBravo (35450)
        +1 in my book.
      • by drinkypoo (153816)

        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.

      • by wjwlsn (94460)

        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.

      • by AdamHaun (43173)

        Thanks! That was exactly the sort of answer I was looking for.

  • DOS (Score:5, Funny)

    by GbrDead (702506) on Sunday March 24, 2013 @04:19AM (#43261791) Homepage

    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.

    • by ls671 (1122017)

      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]

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

    • The problem is, many people seem to have forgotten what an operating system actually is and what it isn't. What they see when they boot up their computers is a user interface. Go ahead and try to explain the difference to someone who grew up with DOS, Windows or Linux :-/
  • Just another OS (Score:4, Insightful)

    by ensignyu (417022) on Sunday March 24, 2013 @04:29AM (#43261807)

    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.

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

    • by CBravo (35450)
      There are a couple of issues that arise on production systems I find:
      -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
      • by KPU (118762)

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

        • by CBravo (35450)

          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.

      • by allo (1728082)

        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.

        • by CBravo (35450)
          Of course we do not start a new kernel for that. We just keep adding cruft after cruft on a machine, no matter how small the cruft. But that is the point. We do that and you end up with a lot of cruft.
  • Xen introduced Mini-OS [xen.org] years ago. The question is: how much functionality that the kernel and a fat libc commonly provides, does the application need. Boot times are not really the issue anymore; look at systemd, everything is booted within 2s.
  • by BitZtream (692029) on Sunday March 24, 2013 @05:39AM (#43261973)

    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.

    • by swillden (191260)

      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)

  • ...is HYPE,

    Nothing to see here, move along

  • This seems like a really latent reimplementation of inetd.

  • Where does the submitter got that "Currently cloud providers round an instance uptime to the full hour when calculating charges."?? Totally bogus. For example Google App Engine maintains an unused, idle instance for "only" 15 minutes and thats what you get billed, not a "full hour" as is claimed here. If you have high load its irrelevant when the instance shuts down. If you have little load it might matter but you will save little since you consume little to begin with.
  • 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

    • by rubycodez (864176)

      But we have OS-less computer systems with human interfaces everywhere, from automobiles to microwave ovens to thermostats.

  • Elastic? For a cloud? Yeah....I suppose.
  • 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.

What this country needs is a good five dollar plasma weapon.

Working...