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.
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...
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."
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?
After a few years of trending toward monoliths via chef/puppet/ansible DevOps automation, Docker is going in a different direction, toward fragmented SOA. It'll go that way for a while until it becomes too painful, and then new tech will come to push us back to the monolithic approach, until that hurts too much...
The good thing is, these cycles come in response to improvements in technology and performance. Our tools get better all the time, and configuration management struggles to keep up. It's awesome! Docker will rule for a while and then be passed by in favor of something new, but it'll leave a permanent mark, just as Chef did, and Maven, and Subversion, and Ant, and Make, and CVS, and every other game-changer.
1. The containers live on "your" VMs so you get the isolation of a virtual machine and do not worry about the other tenants' containers.
2. The VMs are part of a "private cloud", i.e., the internal network is not accessible by other tenants' VMs and containers.
#2 is what worried me the most in other container service offerings. It's easy to overlook protecting your internal ip when you manage VMs, it's even easier (and expected) when you deploy containers.
Basically, you launch a cluster of EC2 instances that are "available" for containers to launch into. So these are your instances, running in your VPCs. It's really the same security profile as the standard VPCs plus any other security issues your particular docker containers expose.
Is this typical for new AWS offerings?
It makes me wonder if it's something that truly isn't ready for prime time, but is being rushed / forced by the mounting Docker hype and GKE announcement.
[1] https://twitter.com/jeffbarr/status/529493907839533056
[2] http://blog.docker.com/2014/04/aws-elastic-beanstalk-launche...
E.g. Amazon Kinesis:
Preview 14 Nov 2013: http://aws.amazon.com/blogs/aws/amazon-kinesis-real-time-pro...
Got access less than week from that.
GA 16 Dec 2013: http://aws.amazon.com/about-aws/whats-new/2013/12/16/amazon-...
...including the Docker repository and image, memory and CPU requirements, and how the containers are linked to each other. You can launch as many tasks as you want from a single task definition file that you can register with the service.
Very few details but it looks like container lifting across hosts. If so this is great news.
To make this not suck you will still need a proxy layer that maps ELB listeners to your containers and if you intend to run containers with persistent storage you are going to be in for a fun ride.
Probably best to integrate functionality for interacting with storage systems into Docker itself, probably as a script hook interface similar to the way Xen works.
