I view containers as more of a reworking of a key computational abstraction (VMs) than an evolution of them. We finally have operating systems with enough inter-process isolation, sufficiently capable filesystems (layering), etc. that we can throw out 80% of the other unnecessary junk of VMs like second kernels, duplicate schedulers, endless duplication of standard system libraries, etc.
So it's more like we've hacked/refactored virtualization into a more usable state, and gotten rid of a lot of useless garbage that it turns out we didn't actually need. It's a lot like how a big software system evolves, now that I think about it.
I ask because I'm familiar with VMs, having worked with them extensively for a number of years. VMs work quite well for any application I've needed, so what would be the benefit of switching to containers? I've got lots to do, and lots to learn, but I can't see learning containers (and being out of sync with the rest of my coworkers) being a priority.
But I'm willing to change my mind if there's a concrete benefit. Right now, VMs work just fine, but maybe there's something I'm missing...
They're fine for a lot of things, of course. I use them all the time. But I use containers for other things.
I expect startup time and memory usage would be lower, but to my mind the advantages are mainly around flexibility... e.g. How long it takes to create or upload an image file. How long it takes to set up a minimal infrastructure with several components to it on a single EC2 instance. Decoupling the operating system patch cycle from the app deployment image generation cycle. etc.
As an example i am running around 20 containerized servers on my Laptop in a 4GB VM which would typically be run on 20 distinct VMs on one or more hypervisors. It's not very fast but the density of servers you can put on your hardware is MUCH bigger.
That's actually exactly why I would use a VM..
The best I've managed was ninety seconds on my own hardware and three minutes (on average) in AWS.
I can't really think of a use case though where someone would need more capacity in sub 10 seconds. Maybe if you only intend to scale horizontally with a bunch of 500Mb instances and had little to no room to set an appropriate scaling threshold? What would be a couple examples? With the apps I've seen the past several years generally they have scaling thresholds at 'X' resource and 3 minutes is more than enough to provision extra capacity for their needs.
You need to start 10 containers locally to dev your app. Spinning up a local 10 VMs kind of sucks. 10 containers can be pretty quick.
(now if you really need 10 containers is another question, and some people clearly over split their architecture).
A SaaS app running in production should be about the size of your binary, and the libraries it uses. Instead, we have X, smtp, terminals and a full filesystem running. home directories and uids make no sense in an app that uses no unix users except for the one you're forced to use.
I'd really like to see a much smaller, simpler, non-posix OS for running server apps.
"OSv was designed from the ground up to execute a single application on top of a hypervisor... OSv... runs unmodified Linux applications (most of Linux's ABI is supported) and in particular can run an unmodified JVM, and applications built on top of one."
1: http://www.linux.com/news/enterprise/cloud-computing/751156-... 2: http://www.openmirage.org/
The POSIX system interfaces (read, write, open, close, etc.) are OK. It's the Commands and Utilities that are the problem. Do you really need Bash available? How much of the 50,000,000 lines of Linux need to be inside your VM running your one web application? How much attack service is provided by the presence of all that stuff?
There's a project which has taken the C runtime library and made it run on a bare VM, so you don't need an OS instance at all. If you're just running one program, that makes a lot of sense.
Second, POSIX is a standard for how the operating system API works that has nothing to do with what packages are installed -- and it's a pretty low-level API, for doing stuff like read, write, fork, exec, etc. This isn't what's adding bloat.
Containers are just a big wad of duct tape holding together the ball of mud that comprises most web applications' server-side components.
Add containers, and you haven't solved the problem, you've just made two problems.
Take all the nastiness and throw it into a box, without needing to contact Ops to reserve memory and provision a VM.
IMO, it's one of the major reasons why Enterprises get so excited about Docker. Legacy app dependency issues are horrible once you get past a certain scale.
VM's are expensive and non-self-service at most orgs since they tie up RAM and licenses.
Does this sound true to you? What makes containers any different from the organization that the abstraction of "functions" bring to ordinary sequential programs?
Functions (should) abstract over irreducible complexity.
As long as we're asking hypotheticals — why do applications need to control the global OS namespace and the dependencies between elements in that namespace to a degree that the applications themselves can't be easily deployed without containers?
Can that problem be reduced?
If not, why not?
That's what "containers" are, of course. There's so much state in OS file namespaces that running any complex program requires "installation" first. That's such a mess that virtual machines were created to allow a custom OS environment for a program. Then that turned into a mess, with, for example, a large number of canned AWS instances to choose from. So now we have another level of indirection, "containers".
Next I expect we'll have container logistics management startups. These will store your container in a cloud-based "warehouse", and will continuously take bids for container execution resources. Containers will be automatically moved around from Amazon to Google to Rackspace, etc. depending on who's offering the lowest bid right now.