Slashdot Mirror

← Back to Stories (view on slashdot.org)

A Glimpse of a Truly Elastic Cloud

Posted by timothy on 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."

39 of 201 comments (clear)

  1. A runtime system is an OS by Anonymous Coward · · 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.

    1. Re:A runtime system is an OS by Anonymous Coward · · 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.

    2. Re:A runtime system is an OS by Anonymous Coward · · Score: 3, Funny

      So, the os then.

    3. Re:A runtime system is an OS by Ferzerp · · Score: 2

      And not a hypervisor at that point, but just an OS executing applications. Oh how novel!

    4. Re:A runtime system is an OS by squiggleslash · · Score: 4, Insightful

      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.

      --
      You are not alone. This is not normal. None of this is normal.
    5. Re:A runtime system is an OS by Ritchie70 · · Score: 2

      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 of semantics as to what you call it. Apparently the current fashion is to call a new OS a hypervisor instead of an OS. Probably because it's easier to sell people on a new hyervisor than it is to sell them on a new OS when we already have so many of those.

      --
      The preferred solution is to not have a problem.
  2. "stop using OSes"? by 1u3hr · · Score: 5, Insightful

    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.

    1. Re:"stop using OSes"? by julesh · · 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).

    2. Re:"stop using OSes"? by ls671 · · 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.

      --
      Everything I write is lies, read between the lines.
    3. Re:"stop using OSes"? by Bert64 · · Score: 2

      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.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    4. Re:"stop using OSes"? by itsdapead · · Score: 4, 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.

      --
      In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
    5. Re:"stop using OSes"? by Shinobi · · Score: 2

      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.

    6. Re:"stop using OSes"? by Goaway · · Score: 3, Insightful

      No. That would be stretching the meaning of the word so far it becomes meaningless.

    7. Re:"stop using OSes"? by ChronoFish · · Score: 3, Insightful

      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

    8. Re:"stop using OSes"? by nemesisrocks · · Score: 2

      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?

  3. A real server OS. by Animats · · Score: 4, 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.

    1. Re:A real server OS. by AmiMoJo · · Score: 4, 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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    2. Re:A real server OS. by Let's+All+Be+Chinese · · Score: 4, Insightful

      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.

    3. Re:A real server OS. by ultranova · · Score: 3, Funny

      Why not simply have a single instance of linux, and then multiple instances of erlang running under that linux kernel?

      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.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

  4. Still an OS... by FaxeTheCat · · Score: 5, Insightful

    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.

    1. Re:Still an OS... by julesh · · Score: 4, 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?

    2. Re:Still an OS... by vsov · · Score: 2

      That would be KVM or lxc way, which also possible :) In our humble opinion Xen has better potential to be a node-level hypervisor for large cloud platforms. It already is, in Amazon, Rackspace, etc., actually, Xen is the standard hypervisor for public clouds. Of course, to be able to run instances in Amazon, we had to start from Xen. Moreover, when you running Xen you don't need to consider Linux-specific process scheduler and memory management, thus there's no need to give up the control on very important things. Migration things from Linux within is also problematic, Xen gives that functionality for no additional cost. In short, there were reasons to choose Xen.

  5. Minimum != No by rok3 · · Score: 2

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

    1. Re:Minimum != No by vsov · · Score: 2

      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 hypervisor, Dom0 and in cloud services.

  6. Re:Link? by Anonymous Coward · · 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't look like a sweet spot at all.

  7. Reusable OS-less instances by FaxeTheCat · · Score: 2

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

  8. Not quite OS-less, but still sounds neat by AdamHaun · · Score: 4, Interesting

    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.

    --
    Visit the
    1. Re:Not quite OS-less, but still sounds neat by julesh · · Score: 3, 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.

    2. Re:Not quite OS-less, but still sounds neat by bertok · · Score: 4, 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.

    3. Re:Not quite OS-less, but still sounds neat by drinkypoo · · Score: 2

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  9. DOS by GbrDead · · Score: 4, 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.

    1. Re:DOS by Floyd-ATC · · Score: 2

      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 :-/

      --
      Time flies when you don't know what you're doing
    2. Re:DOS by transporter_ii · · Score: 2

      Look at Desqview: http://en.wikipedia.org/wiki/DESQview

      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.

      --
      Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
  10. Just another OS by ensignyu · · Score: 3, 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.

  11. Re:Foreign link to libvert, not Erlang-specific by vsov · · Score: 2

    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.

  12. Awesome performance by BitZtream · · Score: 3, 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.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    1. Re:Awesome performance by swillden · · Score: 2

      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) in response to the ebb and flow of demand.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  13. Re:Editors? by ldobehardcore · · Score: 2

    Whoosh.

    --
    Hectice, baby, Mercator says hello to you
  14. Re:A true cluster operating system has not been ma by rubycodez · · Score: 2

    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