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

Docker needs an OS to run, duh!

[Anonymous Coward]

Remember Matthew 7:26: A foolish man built his house on sand.

Re:Docker needs an OS to run, duh!

[DivineKnight]

What does it say about condensed water vapor?

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:Docker needs an OS to run, duh!

[jandersen]

Remember Matthew 7:26: A foolish man built his house on sand.

- and what is silicon made from? ;-)

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!

[Urkki]

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

Re:Of Course They Do!

[phantomfive]

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

[Anonymous Coward]

Servers are for techie losers. The Cloud is the hip shit, bro.

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:Advert?

[invalid-access]

In what sense is a Docker container thicker than a VM? I always thought it was thinner/lighter - e.g. A host can allocate varying amounts of memory to a container (with optional limits). Whereas running a VM will always put you back that much memory on its host.

Re:Advert?

[jbolden]

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:

Portable deployment across machines. Docker defines a format for bundling an application and all its dependencies into a single object which can be transferred to any Docker-enabled machine, and executed there with the guarantee that the execution environment exposed to the application will be the same. LXC implements process sandboxing, which is an important pre-requisite for portable deployment, but that alone is not enough for portable deployment. If you sent me a copy of your application installed in a custom LXC configuration, it would almost certainly not run on my machine the way it does on yours, because it is tied to your machine's specific configuration: networking, storage, logging, distro, etc. Docker defines an abstraction for these machine-specific settings, so that the exact same Docker container can run - unchanged - on many different machines, with many different configurations.

Application-centric. Docker is optimized for the deployment of applications, as opposed to machines. This is reflected in its API, user interface, design philosophy and documentation. By contrast, the lxc helper scripts focus on containers as lightweight machines - basically servers that boot faster and need less RAM. We think there's more to containers than just that.

Automatic build. Docker includes a tool for developers to automatically assemble a container from their source code, with full control over application dependencies, build tools, packaging etc. They are free to use make, maven, chef, puppet, salt, Debian packages, RPMs, source tarballs, or any combination of the above, regardless of the configuration of the machines.

Versioning. Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc. The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer. Docker also implements incremental uploads and downloads, similar to git pull, so new versions of a container can be transferred by only sending diffs.

Component re-use. Any container can be used as a "base image" to create more specialized components. This can be done manually or as part of an automated build. For example you can prepare the ideal Python environment, and use it as a base for 10 different applications. Your ideal Postgresql setup can be re-used for all your future projects. And so on.

Sharing. Docker has access to a public registry where thousands of people have uploaded useful containers: anything from Redis, CouchDB, Postgres to IRC bouncers to Rails app servers to Hadoop to base images for various Linux distros. The registry also includes an official "standard library" of useful containers maintained by the Docker team. The registry itself is open-source, so anyone can deploy their own registry to store and transfer private containers, for internal server deployments for example.

Tool ecosystem. Docker defines an API for automating and customizing the creation and deployment of containers. There are a huge number of tools integrating with Docker to extend its capabilities. PaaS-like deployment (Dokku, Deis, Flynn), multi-node orchestration (Maestro, Salt, Mesos, Openstack Nova), management dashboards (docker-ui, Openstack Horizon, Shipyard), configuration management (Chef, Puppet), continuous integration (Jenkins, Strider, Travis), etc. Docker is rapidly establishing itself as the standard for container-based tooling.

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:Everything new is old

[perpenso]

"Personal Computers" not "computers". We also had mainframe, minicomputers and workstations that were pretty good at running multiple programs in parallel.

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.

Re: People seem to be forgetting what a server is

[DivineKnight]

+1, Funny for the BOFH style response.

Re:Who's wondering this?

[timeOday]

I question it. When you're running a database implemented in Java on a filesystem in an OS inside a VM on a filesystem inside another OS on virtual memory/paging hardware, that's 8 levels of largely redundant access control / containerization / indirection. It's a supreme mess and imposes a big burden of runtime cost and more importantly the burden of configuring all those layers of access control.

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.

A horrible nightmare...

[Junta]

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.

Re:People seem to be forgetting what a server is

[mrchaotica]

It seems to me that a lot of the performance tuning knowledge is getting lost on a large percentage of devs

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