Operating Systems Still Matter In a Containerized World

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.

Comments

Of Course They Do!

[Anonymous Coward]

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!

[DivineKnight]

I can't wait for programmers, sometime in 2020, to rediscover the performance boost they receive running an OS on 'bare metal'...

Re:Of Course They Do!

[Urkki]

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:Of Course They Do!

[perpenso]

How would you even know if it's running?

The morse code on an LED

Re:Of Course They Do!

[philip.paradis]

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

Advert?

[Anonymous Coward]

Is this just an advert for Docker?

Re:Advert?

[ShanghaiBill]

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:People seem to be forgetting what a server is

[DivineKnight]

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

Everything new is old

[starfishsystems]

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

Re:Docker needs an OS to run, duh!

[perpenso]

What does it say about condensed water vapor?

It varies. Sometimes it says beware. Other times it says that people prefer wine.

Re: People seem to be forgetting what a server is

[frikken lazerz]

The server is the guy who brings me my food at restaurants. I guess people aren't eating at restaurants anymore because the economy is tough.

what are you smoking?

[Chirs]

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:what are you smoking?

[serviscope_minor]

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.