Operating Systems Still Matter In a Containerized World 129
New submitter Jason Baker writes: With the rise of Docker containers as an alternative for deploying complex server-based applications, one might wonder, does the operating system even matter anymore? Certainly the question gets asked periodically. Gordon Haff makes the argument on Opensource.com that the operating system is still very much alive and kicking, and that a hardened, tuned, reliable operating system is just as important to the success of applications as it was in the pre-container data center.
Docker needs an OS to run, duh! (Score:2, Insightful)
Remember Matthew 7:26: A foolish man built his house on sand.
Re: (Score:2)
What does it say about condensed water vapor?
Re:Docker needs an OS to run, duh! (Score:4, Funny)
What does it say about condensed water vapor?
It varies. Sometimes it says beware. Other times it says that people prefer wine.
Re: (Score:3)
Remember Matthew 7:26: A foolish man built his house on sand.
- and what is silicon made from? ;-)
Re: (Score:2)
Listen, lad. I've built this kingdom up from nothing. When I started here, all there was was swamp. All the kings said I was daft to build a castle in a swamp, but I built it all the same, just to show 'em. It sank into the swamp. So, I built a second one. That sank into the swamp. So I built a third one. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. An' that's what your gonna get, lad -- the strongest castle in these islands.
Re: (Score:2)
I spent several minutes reading "What is it?" on docker's website, and I still don't understand what it is. Is it like a JVM?
Re: (Score:1)
Re: (Score:2)
I thought it was "A foolish man built his house on sand, while the geek built his house in Minecraft."
People seem to be forgetting what a server is (Score:1)
I blame the cloud.
Re: (Score:2, Funny)
Servers are for techie losers. The Cloud is the hip shit, bro.
Re:People seem to be forgetting what a server is (Score:5, Funny)
More along the lines of "they never knew what a server was, and would artfully dodge your phone calls, elevator meetings, and eye contact to avoid accidentally imbibing any knowledge that might furnish them with this understanding; all they know is that the slick salesman with the nice sports car and itemized billing said they'd magically do everything from their end and never bother them, and they believed them."
Re: People seem to be forgetting what a server is (Score:5, Funny)
Re: (Score:2)
+1, Funny for the BOFH style response.
Re: (Score:2)
Re: (Score:2)
Deal with client side developers all the time asking for 100MB of data "right now" across an internet pipe (which might be coming from africa or some place with really bad service): why shouldn't we get all the data at the same time? It seems to me that a lot of the performance tuning knowledge is getting lost on a large percentage of devs: the solution is always get someone to get you a fatter internet pipe, bigger server, drop everything and try a new framework etc. Server side developers do it too: "we h
Re: (Score:2)
one way or the other this is going to solve it self, right ?
Or pipes, etc. get a lot bigger (things like silicon photonics in the data center and NVRAM will help) or people with more knowledge of the problem will find a better job.
Re: (Score:3)
As a web developer I'd like to care about such things, but I spend all my time four or five layers of abstraction away from the server and all the performance-related backlogs are prioritized so far behind new revenue-producing features that they'll happen sometime between "six decades from now" and "heat death of the universe."
Re: (Score:2)
My experience is that is generally the case. The problem with performance: you have to convince your boss to spend a month looking into something that "might" help vs doing something they think will get customers. That said often new features are pulled out of their or distributors hats hoping that it is something the customer will actually care about. Web solutions should help with the monitization of performance a bit: you can directly relate people leaving your site to the latency they experienced, can r
Of Course They Do! (Score:5, Interesting)
Stripped to the bone, an operating system is a set of APIs that abstract the real or virtual hardware to make applications buildable by mere mortals. Some work better than others under various circumstances, so the OS matters no matter where it's running.
Re:Of Course They Do! (Score:5, Interesting)
I can't wait for programmers, sometime in 2020, to rediscover the performance boost they receive running an OS on 'bare metal'...
Re: (Score:2)
Except there will be no performance boost. There may be a blip in some benchmark.
Additionally, programmers are already running *application code* on bare metal when that kind of performance matters, most commonly on GPUs.
Re: (Score:2)
It's kind of silly but no worse than network file systems. And, containers don't have that virtualization overhead.
Re:Of Course They Do! (Score:5, Informative)
Modern virtualization doesn't have the overhead the GP cited; the 20% RAM loss and 30% CPU capacity loss numbers cited by the AC you responded to are absurd fabrications. I use KVM on Debian hosts to power a large number of VMs running a variety of operating systems, and the loss of CPU bandwidth and throughput with guests is negligible due to hardware virt extensions in modern CPUs (where "modern" in fact means "most 64-bit AMD and Intel CPUs from the last few years, plus a small number of 32-bit CPUs"). Using the "host" CPU setting in guests can also directly expose all host CPU facilities, resulting in virtually no losses in capabilities for mathematically-intensive guest operations. As far as memory is concerned, far from resulting in a 20% loss of available RAM, I gain a significant amount of efficiency in overall memory utilization using KSM [linux-kvm.org] (again, used with KVM). On a host running many similar guests, extremely large gains in memory deduplication may be seen. Running without KSM doesn't result in significant memory consumption overhead either, as KVM itself hardly uses any RAM.
The only significant area of loss seen with modern virtualization is disk IO performance, but this may be largely mitigated through use of correctly tuned guest VM settings and updated VirtIO drivers. The poster you replied to is ignorant at best, and trolling at worst.
Re: (Score:2)
In my experience, KSM hasn't helped as much as it promised. It depends heavily upon the workloads. It also impacts memory performance. If things are such that KSM can be highly effective, then a container solution would probably be more prudent.
Re: (Score:2)
KSM efficacy is of course workload dependent; I specifically nodded to this factor as follows:
On a host running many similar guests, extremely large gains in memory deduplication may be seen.
I'm not experiencing issues with memory performance. Could you cite specific data you've collected in your environment? Perhaps huge pages [debian.org] would be helpful for your use case.
Assuming more than a handful of application instances, a container solution is nearly certain to be less prudent. Please feel free to reach out to me via email [mailto] if you'd like to collaborate on potentially better approaches to the problems you're
Re: (Score:2)
I like how you didn't bother to directly respond to any of the points listed. Your apparent inability to properly tune a virtualization host and its guests is your problem, and not reflective of the current abilities offered by modern virtualization systems. To address your point regarding GPU losses, if you're really that concerned about such issues on server systems, you're welcome to give host passthrough a shot with one of your guests; a lot of nice work has been done in that area lately. That said, th
Re: (Score:2)
Admittedly anecdotal but when working from home a few months back I had issues with the VPN software not liking win 8. I ended up running virtualbox + xp. I noticed the network performance was way slower (things like loading webpages) when using the vm (even when not connected to the vpn) vs "local" machine. I had GPU optimizations turned on, I had all cores and a lot of ram allocated to the vm and didn't appear to be resource constrained (va task man/perf mon on the host os) etc. There does seem to be a pe
Re: (Score:2)
VirtualBox isn't representative of the majority of the use cases under discussion here. I work with large KVM and VMware ESX deployments every day, and every single file and database server I use in enterprise environments is virtualized. Performance is not a problem, even for heavy workloads. Latency is not an issue, either. I won't beat a dead horse in this thread, but I will offer my advice via email [mailto] if you'd like a few additional ideas regarding your stated use case.
Re: (Score:2)
I use the tool I have for the job I'm doing. Please take your zealotry to the middle east. It is only appreciated there.
what are you smoking? (Score:5, Interesting)
Anything performance-sensitive isn't going to use emulation but rather paravirtualization or passthrough of physical devices. Current x86 virtualization is getting pretty good, with minimal hit to CPU-intensive code. As for I/O, you can pass through PCI devices in to the guest for pretty-much native networking performance.
Disk I/O still isn't as good as native, but it's good enough, and most enterprise systems are using ISCSI anyway to allow for efficient live migration.
Re: (Score:2)
Re: (Score:1)
iSCSI is absurdly, ungodly slow unless you use accelerators on both the initiator and the target. Far better to use ATAoE, and if you do invest in accelerators, it's far better to go for FCoE or RoCE.
Technically iSCSI is a lousy protocol, the only reason it's got any traction is because of a bunch of industry vested interests. Don't believe me, go and read the spec, or try benchmarking ATAoE and iSCSI side by side.
We have 5000 nodes running ATAoE. Not exactly a large site, but not exactly a small site eithe
Re:what are you smoking? (Score:4, Informative)
Yeah but there's the memory penalty, and the conflicting CPU schedulers.
If you have 20VMs basically running the same code, then all of the code segments are going to be the same. So, people are doing memory deduplication. Of course that's inefficient, so I expect people are looking at paravirtualising that too.
That way you'll be able to inform the VM sysrem that you're loading an immutable chunk of code and if anyone else want's to use it their free to. So it becomes an object of some sort which is shared.
And thus people will have inefficiently reinvented shared objects, and will probably index them by hash or something.
The same will happen with CPU scheduling too. The guest and host both have ideas who wants CPU when. The guests can already yield. Sooner or later they'll be able to inform the host that they want some CPU too.
And thus was reinvented the concept of a process with threads.
And sooner or later, people will start running apps straight on the VM because all these things it provides are basically enough to run a program so why bother with the host OS. Or perhaps they won't.
But either way people will find that the host OS becomes a bit tied down to a particular host (or not---and thus people reinvent portability layers) and that makes deployment hard so wouldn't it be nice if we could somehow share just the essentials of the hardware between multiple hosts to fully utilise our machines.
Except that's inefficient and there's a lot of guess work so if we allow the hosts and the host-hosts to share just a liiiiiiiitle bit of information we'll be able to make things much more efficient.
And so it continues.
Re: (Score:2)
It's worth mentioning that device passthrough requires CPU extensions and motherboard support, and this doesn't seem well supported outside of solid server gear.
Re: (Score:2)
As for I/O, you can pass through PCI devices in to the guest for pretty-much native networking performance.
Of course, that comes with its own headaches and negates some of the benefits of a VM architecture. Paravirtualized networking is however pretty adequate for most workloads.
It's not like you have to do VM *or* baremetal across the board anyway. Use what makes sense for the circumstance.
Re:Of Course They Do! (Score:5, Informative)
First, assumption is that we're talking about the kind of virtual machines people run in VirtualBox etc, using the native CPUs etc. IOW, not talking about emulators like QEMU.
VM host RAM overhead is essentially static, while VM guest memory sizes go up along with all memory sizes, so actually RAM overhead asymptotically approaches 0%.
30% CPU, just how do you get that number? Virtual memory page switches etc may have some overhead in VM maybe, I don't know, but normal application code runs at the raw CPU just like code on the host OS.
And there's normally no emulation of hardware, there's just virtualization of hardware in the normal use cases. Hardware can also be directly connected to the VM at the lowest possible level, bypassing most of the host OS driver layers (non-performance-related, this is very convenient with mice and keyboards in multi-monitor setups, where each monitor can have a VM in full screen with dedicated kb&mouse in front of it, no more looking at one VM while focus is in another).
Re: (Score:2)
Note that discussion is about users noticing performance gain with OS running on bare metal in the year 2020. At that time, with harware of that time, they'll need a benchmarking software to notice the difference between native and VM host, even for stuff like games.
In fact, at that time, I think state-of-the-art games etc PC software will be delivered as VM images, because the OS part of those images is going to be so small part of total size of the game that it is inconsequential, and developing against a
Re: (Score:1)
And for VoIP the unpredictable scheduling you get by running within a VM can have a massive negative impact on audio quality. And gets even worse if another VM decides it needs more CPU (stolen CPU time).
It's bad for anything that needs low latency or reliable timing.
Re: (Score:1)
Re: (Score:2)
CPU throughput impact is nearly undetectable nowadays. Memory *capacity* can suffer (you have overhead of the hypervisor footprint), though memory *performance* can also be pretty much on par with bare metal memory.
On hard disks and networking, things get a bit more complicated. In the most naive way, what you describe is true, a huge loss for emulating devices. However paravirtualized network and disk is pretty common which brings it in the same ballpark as not being in a VM. But that ballpark is relat
Re: (Score:2)
Re: (Score:2)
The point of Docker and containers in general is that they are running at basically native performance. There is no vm, no virtualized OS, you run under the main OS kernel, but it don't let you see the main OS filesystem, network, processes and so on, and don't let you do operations risky for the stability of the main system. There is some overhead in the filesystem access (in the case of docker, you may be running on AUFS, device mapper, or others that will have different kind of impact in several operatio
Re: (Score:2)
No, stripped to the bone, operating system offers no APIs at all, and it will not run any user applications. It will just tend to itself. Then you add some possibilities for user applications to do things, the less the better, from security and stability point of view. Every public API is a potential vulnerability, a potential window to exploit some bug.
Re: (Score:2)
No, stripped to the bone, operating system offers no APIs at all, and it will not run any user applications.
Uh, what would be the point of such an operating system?
Re: (Score:3)
No, stripped to the bone, operating system offers no APIs at all, and it will not run any user applications.
Uh, what would be the point of such an operating system?
Point would be to have a stripped to the bone OS.
Actually it's kind of same as having a stripped to the bone animal (ie. skeleton): you can for example study it, put it on display, give it to the kids to play with... ;)
Re: (Score:2)
Re:Of Course They Do! (Score:4, Funny)
How would you even know if it's running?
The morse code on an LED
Re: (Score:2)
How would you even know if it's running?
Well, for the totally barebone version, you could run it in a VM and examine its memory contents there.
I think even barebone OS would need *some* functionality. It would have to be able to shut itself down, on PC probably by ACPI events. It would probably need to be able to start the first process/program, because I think an OS has to be able to do that, even if that process then wouldn't be able able to do anything due to lack of APIs. Etc. So even barebone, it still needs to do something.
More practical th
Re: (Score:3)
It would have to be able to shut itself down, on PC probably by ACPI events.
Oh, that's communication, then you can hack it.
Re: (Score:2)
Or
It would have to be able to shut itself down, on PC probably by ACPI events.
Oh, that's communication, then you can hack it.
I don't know, it could be made to be one-time trigger, which starts the shutdown. If there's no way to get altered input through, that will not allow hacking. It should be simple enough to,be made bug-free.
Re: (Score:2)
It should be simple enough to,be made bug-free.
I have a book that talks about reliable design. On one page, they demonstrate that they have a 4-line program without any bugs.
Then in the next paragraph, they admit that the first few versions had bugs.
Re: (Score:2)
Isn't that what a default OpenBSD installation is about?
Re: (Score:2)
"No, stripped to the bone, operating system offers no APIs at all"
I think we called those Kernels and it's already done in the linux and bsd world not windows.
Mmm, yeah, a barebone OS would not have almost anything except the kernel. But Linux and BSD kernels offer a complex API: all the system calls. Not barebone at all.
Re: (Score:2)
Contrast that with Android and iOS, where this functionality isn't abstracted away from the application, and any application that wants to access a network drive or the default cloud drive (Google
Advert? (Score:5, Insightful)
Is this just an advert for Docker?
Re:Advert? (Score:5, Interesting)
Is this just an advert for Docker?
Yes. They refer to the "rise" of Docker, yet I had never heard of it before. Furthermore, Docker doesn't even fit with the main point of TFA that "the OS doesn't matter". Here is a complete, exhaustive list of all the OSes that Docker can run on:
1. Linux
Re: (Score:2)
Docker is legit and important. There are a 1/2 dozen of these containerized OSes. Docker is the most flexible (it runs on a wide range of Linuxes while most of them are specific to a particular cloud vendor). It is also the most comprehensive though SoftLayer's and Azure's might pass it in that regard. A Docker container is thicker than a VM, thinner than a full Linux distribution running on a VM. It is more accurate to consider Docker an alternative to VMs and Linux distributions running in each VM.
Re: (Score:2)
Re: (Score:2)
The Docker Engine is much thicker than a hypervisor essentially containing the full suite of services of the guest OS.
Re: (Score:1)
I don't understand what you mean.
Docker is nothing more than a configuration interface for Linux Containers (a feature of the Linux kernel). The engine is not an hypervisor. A "dockerized" VM could be seen as a chrooted directory (or mountpoint) with its own PIDs, FDs, sub-mountpoints, network interfaces, etc.
It shares the kernel of the "real machine". It's also based on the "real kernel" services for everything.
I doubt there could be anything lighter.
It just has its own init, so everything inside the VM is
Re: (Score:2)
Containers play the role of VMs. They are competing paradigms for how to deploy services. The Docker engine is responsible for allocating resources to, terminating and starting containers which is what the hypervisor does.
Re: (Score:2)
Docker has an engine? I haven't actually used Docker yet because I've already been using LXC for some years and just haven't had a "free day" to play with it. But I've always been under the impression that Docker was just a abstraction around LXC making containers easier to create. Is the Docker "engine" actually LXC?
Serious question because the main reason I haven't invested in Docker is my perception that it won't really save (me) time if you already well understand LXC. Is there some other benefit be
Re: (Score:3)
No the engine uses LXC as a component. There is a lot more to Docker then just LXC. But this comes up a lot so it is in the FAQ and I'll just quote the FAQ: Docker is not a replacement for LXC. "LXC" refers to capabilities of the Linux kernel (specifically namespaces and control groups) which allow sandboxing processes from one another, and controlling their resource allocations. On top of this low-level foundation of kernel features, Docker offers a high-level tool with several powerful functionalities:
Re: (Score:1)
You are mistaken with regard to the relationship Docker has (technically, had) with LXC. When Docker was originally created, it basically sat on top of LXC and used its capabilities for containers. Nowadays, it uses libcontainer underneath its abstractions and doesn't use LXC at all.
Re: (Score:2)
OK, so it's kind of like Crossover Games -- it creates a wrapper with everything that an app (game) needs from an OS, but doesn't require the entire OS.
You are basically then allocating memory and feeding tasks to the wrapper without expending resources you don't need. To describe what it can and cannot do, all you can say is; "it depends."
Is that about right?
Re: (Score:2)
Sort of. Using your analogy the wrapper in this case is full featured and has all the capacities (plus a bit more) of a Linux for almost all applications. Each applications only needs a library set that aren't provided by Docker. And of course Docker can be modified so if you need the same library over and over... it can be added to the wrapper.
Re: (Score:1)
So because you personally have never heard of Docker before, this story must be a slashvertisement?
That's some interesting logic.
Re: (Score:2)
So because you personally knew about Docker before, this means everybody should know about it too?
That's some interesting logic.
Re: (Score:1)
https://yourlogicalfallacyis.c... [yourlogicalfallacyis.com]
Here's a nickel, kid. Buy yourself a better argument.
Re: (Score:2)
It was the same argument as your own.
Re: (Score:1)
I suppose it might seem that way to an idiot.
Re: (Score:2)
I'm glad to know you found out the problem about this argument. Yourself.
Re: (Score:2)
You're one of those people who thrive on thinking they're right while being so, so wrong. No wonder you're a libertarian.
Re: (Score:2)
And you're so ignorant that you think everyone is an American.
By the way, the Internet connects people from all over the world, not just the U.S.A.
Re: (Score:2)
I never said you were an American, and somehow you're not denying being a libertarian.
Do they not teach you how to read anything in libertopia, or is this level of idiocy an acquired skill?
Re: (Score:2)
Will I need to deny anything I'm not to satisfy your curiosity?
Alright then. I'm not a rock, a computer, a meat popsicle, a desk, a cloud, a car, a building, a libertarian, a democrat, a republican, a republicrat, a demopublican, a popcorn kernel, a shoe, a plane, an iPod, a granola bar, a microwave oven, an Android phone, an A.I., a door, a truck... do I really need to list everything?
This is just getting annoying. Let's put each other on our "enemies" list and be done with it.
Re: (Score:2)
I don't believe you.
Everything new is old (Score:5, Insightful)
What? I had to read this a couple of times. The historic norm was for a single operating system to serve multiple applications. Only with the advent of distributed computing did it become feasible, and only with commodity hardware did it become cost-effective, to dedicate a system instance to a single application. Specialized systems for special purposes came into use first, but the phenomenon didn't really begin to take off in a general way until around 1995.
Re: (Score:2)
"The operating system is therefore not being configured, tuned, integrated, and ultimately married to a single application as was the historic norm, but it's no less important for that change."
What? I had to read this a couple of times. The historic norm was for a single operating system to serve multiple applications. Only with the advent of distributed computing did it become feasible, and only with commodity hardware did it become cost-effective, to dedicate a system instance to a single application. Specialized systems for special purposes came into use first, but the phenomenon didn't really begin to take off in a general way until around 1995.
Going to point out in the DOS days, you've have different memory setups for different stuff. Plenty of apps (mostly games though) required a reboot to get the correct memory manager set up for it. Granted, this was a 640k barrier problem, and the main OS didn't actually load/not load anything different, just the memory managers and possible 3rd party programs.
Even back on the C64 days you'd have to reboot the computer after playing a game, since you didn't normally have a way to exit it. Granted that w
Re: (Score:3)
Re: (Score:2)
OS2 was real good at running older dos apps / games.
Re: (Score:2)
Despite the name, DOS was not an operating system
Re: (Score:2)
DOS was just a niche, not even a real OS, and only around for a small fraction of the time operating systems have been around. Unless you mean mainframe DOS instead of PC stuff. Even by the standards of a time it wasn't an OS.
Re: (Score:2)
Re: (Score:2)
To clarify a bit, I was referring to the period between 1960 and today, when multiprocessing systems established what could properly be called the "historic norm" for the industry. That's the lineage, starting with mainframes, which led directly to virtualization. In fact we were working on primitive virtualization and hypervisors even then, though for the sake of faster system restarts, live failovers and upgrades rather than anything like the cloud services of today. I hadn't thought to include hobbyist systems in this account because they're not really part of this lineage. It was a long time before they became powerful enough to borrow from it. What they did contribute was an explosion in commodity hardware, so that when networking became ubiquitous it became economical to dedicate systems to a single application. But that comes quite late in the story.
Ya, I ended up doing what i said in the last part of my post and didn't think of that fact that computers were around before my kid days. =(
Re: (Score:2)
What is old is also new (Score:1)
FreeBSD and Solaris et al have been doing OS level virtualization for years, let's ask them about host security / tuning and build on their experience.
FreeBSD and illumos are also both open with far more experience in this area.
Singling out Linux as the operating system of choice makes him look like a tool.
Hardened Operating Systems (Score:2)
Instead of trying to harden an OS, why not use a system designed to be secure from the start, one that supports multilevel security [wikipedia.org]. The technology was created in response to data processing demands during the Viet Nam conflict, and perfected during the 70s and 80s.
Re: (Score:1)
Windows 8 ? :D
Re: (Score:1)
Both are equally important.
Who's wondering this? (Score:2)
Re: (Score:3)
Re: (Score:2)
Some people like nested virtual machines, some people like candy colored buttons. What else are you going to do with all those resources? :-)
How about getting it to work on an OS first? (Score:1)
Dear Docker, can you make it work on my windows machine? Your scripts don't work.
Of course (Score:1)
Even if you store your data in "the cloud"; that data is stored on a server someplace, and it has to have an operating system.
A horrible nightmare... (Score:3)
So to the extent this conversation does make sense (it is pretty nonsensical in a lot of areas), it refers to a phenomenon I find annoying as hell: application vendors bundle all their OS bits.
Before, if you wanted to run vendor X's software stack, you might have to mate it with a supported OS, but at least vendor X was *only* responsible for the code they produced. Now increasingly vendor X *only* releases an 'appliance and are in practice responsible for the full OS stack despite having no competency to be in that position'. Let's see the anatomy of a recent example of critical update, OpenSSL.
For the systems where the OS has applications installed on top, patches were ready to deploy pretty much immediately, within days of the problem. It was a relatively no-muss affair. Certificate regeneration was an unfortunate hoop to go through, but it's about as painless as it could have been given the circumstances.
For the 'appliances', some *still* do not even have an update for *Heartbleed* (and many more didn't bother with the other OpenSSL updates). Some have updates, but only in versions that also have functional changes in the application that are not desired, and the vendor refuses to backport the relatively simple library change. In many cases, applying an 'update' actually resembles a reinstall. Having to download a full copy of the new image and doing some 'migration' work to have data continuity.
Vendors have traded generally low amounts of effort in initial deployment for unmaintainable messes with respect to updates.
So... it's Java? (Score:1)
Re: (Score:1)
See it with me: one day, we will have clouds inside clouds!
Re: (Score:1)
See it with me: one day, we will have clouds inside clouds!
We run VM managers as VMs today. This is old hat really.
Re: (Score:2)
I was expecting a discussion about Fremantle's win over Hawthorn on the weekend. :)