Slashdot Mirror
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.
Remember Matthew 7:26: A foolish man built his house on sand.
I blame the cloud.
Truly a remarkable insight! We all thought OSes would die and disappear like the dinosaurs did back in the day.
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.
Is this just an advert for Docker?
All of your WILDEST dreams will come true!
"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.
Parity: What to do when the weekend comes.
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.
Instead of trying to harden an OS, why not use a system designed to be secure from the start, one that supports multilevel security. The technology was created in response to data processing demands during the Viet Nam conflict, and perfected during the 70s and 80s.
Yet another containerized OS independent thingy....
Look, these OS wrappers all fail because ultimately they deliver the subset of an OS, and are 1 generation behind. So the OSes add features and the container adds it when *all* of the underlying OS's they support have adopted similar features enabling the wrapper to add it.
So they're always behind, and always a subset of functionality.
And nobody uses them, well except for a few niche apps, because being behind your competitors isn't a viable option.
Marketing docker this way won't help it. It faces this big problem and its not a new problem and they're not the first to try this.
Was anyone really wondering if operating systems no longer mattered? Might as well have gone with "Nothing is different" as your headline.
Yet another containerized OS independent thingy....
How is Docker OS independent? Looks like it only runs on Linux.
Dear Docker, can you make it work on my windows machine? Your scripts don't work.
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.
And i came here expecting discussion about actual docks and containers. Left dissapointed.
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.
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.
XML is like violence. If it doesn't solve the problem, use more.
It runs on any machine as long as the core library is installed, right? Sounds a lot like Java to me.
~Jarmihi