Also you still have to care about instances and AMIs, rather than just containers and dockerfiles, which is a second layer of management.
Also you still have to care about instances and AMIs, rather than just containers and dockerfiles, which is a second layer of management.
At my work, we run containers on top of EC2. We have a system where we can note how much RAM and CPU we want a container to have. This gives us a couple advantages over running regular boxes on EC2.
First, the CPU allocations are soft. If there's idle CPU on a box, it can be allocated to containers that want it. Imagine a 4-ECU box with 4 containers on it, each wanting 1-ECU. If they're all using the CPU equally, they each get an ECU. However, if two of them are idle on the CPU, the other two can burst to 2-ECU. If they were separate EC2 instances, they wouldn't get that burst.
Second, what happens when you want to allocate another 2GB of RAM to a container you've given 14GB of RAM to? Running containers means we can run large EC2 boxes and let an algorithm deal with the backpack problem of how to stuff things into the different EC2 instances with minimal waste. Without containers, we need to step up to the next-sized instance which might have way more RAM than we need, leading to waste.
Along the same lines, we often want to leave a little overhead in the RAM for different processes. Like, the RAM usage shouldn't go over 10GB, but if it goes up to 11GB for a short time, we'd rather let the garbage collector do its thing than kill it. This means leaving a little overhead. Having this little overhead for everything adds up, but sharing it among lots of things on a large box makes it less waste and the in the unlikely even that all of them want the overhead at the same time, some get killed and re-started on different boxes.
Now, why use EC2 rather than physical hardware from SoftLayer or someone else? EC2 allows us to spin up instances fast. If someone needs 10 15GB containers launched, the EC2 instances can be provisioned in a couple minutes and the containers can be launched on them. SoftLayer notes 20-30 minutes for one of their standard configuration physical servers which is pretty good, but a long time to wait if you're trying to scale up for a burst of traffic or trying to batch process some data or whatnot. If you're looking to customize anything, SoftLayer takes 2-4 hours.
There are definitely cases where every last bit of performance counts (and costs money). I've heard stories of Google being maniacal about finding anything that is blocking in some of their systems. I also know a lot of people that worry about overhead that don't even know where most of the time is spent in their own code. I mean, if one is running a Rails app making a cross-country network call in the request tying up that process for 100ms, the overhead of Xen really isn't an issue. That's an extreme example, but for most users I think the convenience and flexibility of containers is the selling point, not eliminating a tiny bit of overhead from Xen.
If you've got a bunch of small one-off services you deploy all the time and want a bit better density and an nicer deploy story, then sure do up a small CoreOS or ECS cluster. Or maybe you're very large and your resource requirements so high that having tons of spare capacity around to run up containers in makes sense.
On the second point, I guess that they'll end up doing that too. When they launched they made a point of running your containers on your instances as a security thing. Over time I think they'll trust Docker enough to ignore it.
Agreed re: 2