Slashdot Mirror
A Glimpse of a Truly Elastic Cloud
New submitter cloudozer writes "Virtual servers in the future may stop using OSes entirely. As recently demonstrated OS-less platforms may change our understanding of how long does it take to bring a server up. A demo server gets created, booted up, configured, runs an application and shuts down in under 1 second. Radically lower startup latency means that the computing infrastructure may be woven strictly on demand, during the processing window allotted for a given request. Currently cloud providers round an instance uptime to the full hour when calculating charges. They might need to switch to per-second billing if OS-less instances get traction. The demo uses a new Erlang runtime system capable of running directly on Xen hypervisor."
If you don't need much from your OS, then trim the OS down. That doesn't mean you're not using an OS. Unless you run bare-metal code, you are using an OS.
What gibberish is this? There is an OS, presumably Xen. Unless we're returning to the 1940s and wiring up tubes to make programs, there is an OS.
The second link goes into the void.
"may change our understanding of how long does it take to bring a server up"
This sentence is writed by no-brains.
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.
libvert 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.
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.
'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.
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 code without any interpretation while still maintain complete isolation from the OS and other processes is the best example of complete virtualization.
The idea of not having an os is false. Obviously there is an os under Xen, it's just the guest that doesn't have an os. So now it's staring to look like SmartOS or Solaris Zones....
Unix is from the 70s. Windows, which was based on VMS, thank you Cutler, is also from the 70s. They were not intended for masses of 28 nm ICs. There simply is no operating system designed to run many programs across thousands of clusters, with cloud like features.
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...
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
Set up and tear down takes some time and consumes (somewhat) valuable resources. This observation about electronic devices is as old as electronics, not just computers even unto the original (re-)wired computers. From that viewpoint, even the roomful of ladies using calculators in parallel had a significant waste, at that time, involved. Now it's setup and tear-down of virtual machines on massively parallel hardware. My, how things have changed. NOT!
The first thing I do after getting a distro running here is take apart the kernel, modify it to strip everything non-relevant to that machine's purpose(s), recompile, link, substitute, and go. Someone else pointed out the sheer (bloated) size of the kernel that attempts far too much, IMNSHO. VM's receive exactly the same treatment whenever a new purpose is identified and they go into my golden master collection. Turning off services, reducing the amount of code, removing as much of the driver base, all this to create not only a reduced memory footprint, but also a reduced demand on the server by all tiers, and a much reduced attack surface. And BTW, I do exactly the same to any version of Windows that I'm playing with at that time. 'Sides, it's always fun to torture the little beasties in my chamber of horrors here.
These things come in waves. Generalized yields to a flood of purpose built [Sofware | Hardware], which yields to a new, sweeping generalized. Lather, wash, rinse, repeat, ad nauseum. So unless you've already plopped down in front of the 'puter with this page up, move along. Nothing new here.
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
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.
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.
Yes, this technology is utterly, unbelievably new.
http://en.wikipedia.org/wiki/VM_%28operating_system%29
And in the future HTML may stop using HREF
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.
Xen introduced Mini-OS 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.
Support Eachother, Copy Dutch Property!
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
One of these days such systems will appear. I hope we made a step in right direction towards that future.
A demo server gets created, booted up, configured, runs an application and shuts down in under 1 second
so you're saying the hypervisor starts an application layer that then runs an application and then shuts down
sounds kinda similar-ish to dalvik (android)... with all the useless shit taken out
useful yes, but the whole "OS-less" and "elastic cloud" stuff just sounds like marketing bullshit
Well, I find the idea interesting. That way, you can instantiate an "appliance", on a barebone OS, and reduce the attack surface to the minimum. A kind of security by isolation, nice for vswitches and other software boxes.
There is a similar projet in OCaml which is going to be integrated in Xen, openmirage ( openmirage.org) and also a micro-hypervisor projet by Intel, NOVA, which is a base upon which Genode OS can run ( https://github.com/IntelLabs/NOVA )
...is HYPE,
Nothing to see here, move along
Tubby or not tubby. Fat is the question
This seems like a really latent reimplementation of inetd.
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
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.
then it will be even faster. Oh... wait... that's a mainframe.
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 traditional operating system for more or less the reason stated. And as personal computers became more powerful and cheaper and even less intended for sharing, they pretty much all came to run an operating system with multi-user security, process scheduling, protection rings, paging, layered device driver architectures that would be familiar to someone who knew MULTICS or OS/360 with TSO.
Now, there will be a specific set of applications, particularly those whose only I/O operations happen across a network, whose operating system requirements may be sufficiently limited they can be inherited from a parent virtual machine - just as there is a specific set of applications of the industrial control type that can run hardwired into interrupt vectors and physical address space. However, to suggest that virtual servers in general in the future may be able to do away with OSs is contrary to historical precendent. And insane.
.
You have to go old old school to see "bare-metal" LISP: Symbolics was a company that create one of the first "stand-alone" Lisp Machines: hardware dedicated to running LISP programs. Interestingly, the first "dot-com" ever was the symbolics.com domain, according to some trivia on wikipedia's symbolics page.
Lisp Machines were also made by some other companies, but did not do as well commercially.
Richard Stallman also has a bit to say about the topic of Lisp Machines, since one of the founders of Symbolics Lisp Machines, Russ Noftsker, was the person who hired Stallman at MIT's AI Lab. See his speech about his Lisp experiences and about writing Gnu EMACS.
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
Elastic? For a cloud? Yeah....I suppose.
I do not respond to cowards. Especially anonymous ones.
This article really isn't about the OS, or lack thereof. It is about a much more seamless cloud computing experience. While the demonstration does not make much sense in real world applications, it does prove that the launch time of a new cloud computing resource can be much closer to the developer's ideal: instantaneous. In practice, a single resource could be paired with a single consumer's session, and remain allocated until their session concludes. From a management perspective within the datacenter there will be OSes involved. But developers will no longer need to concern themselves with OS images or initialization scripts, as is the case with current cloud infrastructure. I, for one, look forward to the introduction of this type of service. It will be a vast improvement over my company's current (necessary) approach, which involves booting new EC2 instances, running install and configuration scripts, fetching and launching our software, detecting that the new resource(s) is/are online, and finally, distributing tasks to the new servers. This process can take upward of 5 minutes. Not an issue given the service we provide, but less responsive than we would like, especially since we pay for the spin-up time add part of the instance hour.
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 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 and could use the ROM BIOS without consequences. Newer machines and operating systems need a BIOS that is compatible with protected mode. Most newer UEFI BIOSs still support the legacy mode.
Back before the IBM PC and MS-DOS, many people ran CP/M. The CP/M OS consisted of a console command processor (CCP), basic disk operating system (BDOS), and basic input output system (BIOS). This is the origin of the acronym.
Unless you bought your CP/M computer from some systems provider (such as Northstar, Osborne, or NLS), you had to write your own BIOS. If you added a peripheral (such as a printer), you often had to modify your BIOS to support it. (The elite BIOS programmers would even include code for I/O redirection.)
Anyone claiming patents on this should take care:
There are too many "os-less" systems out there too mention, and many if not almost all run fine under an appropriate virtualized or emulated environment.
I can't think of a more ineffecient and wasteful in terms of duplicative resources and global management burdons than continued proliferation of virtual machines.
We don't need VM's we need operating systems that don't suck. For example migrating a running program and dependancies between computers should be baked into the OS not abstraction layers that excuse the OS for sucking.
You know how sometimes, some jerk will link to tvropes in a discussion about Star Trek (probably a very important discussion) and you'll wander off clicking this and that, opening new browser tabs, and eventually you don't really care about Star Trek anymore?
Well, you just made me realize I was a few years out of date on the container work happening in the kernel, and now I'm playing with LXC, which is already compiled into my kernel and I didn't even know I had that...
Cool, they recreated inetd!
http://ostatic.com/blog/considering-freebsd-jails
And by "no OS" you mean has an OS.
Unless you want people to have to write all their own libraries and have direct access to (virtual) devices, I have a pretty good feeling you are going to have an OS.
<a>a demo server gets created</a>
Nice work on the link there.
I remember when "they" decided to replace modems for win-modems. Linux users probably remember the frustration and dead ends of trying to make a software modem work under Linux. Hardware is very good at doing its job; at least a lot better than software. Whenever the latter tries to replace the former...we'll probably see a new IT specialty in the horizon soon.
Where doe google app engine fall in this discussion? Isnt it "truly elastic" in the context used in the summary?