When that single web server goes down, it's not so "fast" anymore.

Agreed, though I keep wanting to take the time to get VRRP working with a web server to have redundancy. OpenBSD uses this to coordinate stateful firewalls with 2 or more systems, if 1 goes down all state info is present on the second node which takes over.

Hi, OP author here: I have actually set up a VRRP (well, UCARP) on Docker, so it's possible even to containerize this facet of running a HA ops stack with Docker as the infrastructure. It is however, as you say, it is only used for one active node + a number of fail-overs in case that one goes down. In terms of maintenance (hosts do go down, scheduled downtime is common), it's priceless to have this part of the puzzle portable as well. If you want to check it out, there's a github available here: https://github.com/titpetric/ucarp-ha - and a future article with it is planned as well. It will also become a part of the E-book which I'm currently working on and publishing on leanpub: https://leanpub.com/12fa-docker-golang :)

OK so that runs on the host to the Docker instances. Pretty cool!

That sounds like a fixable problem. I'm pretty sure Erlang programmers could give some tips.

Why is worrying about a single web server going down more worrisome than some part of the Docker stack going down and causing the same issue?

Actually, neither should be a problem if you have enough redundancy :) the hardest part of rolling your own infrastructure is testing mission critical systems (like databases) to be fault tolerant and at the same time reliable. Lots of great projects are out there that address some of these issues, but it takes a lot of attention to details (like transaction rates, ACID compliance, replication, etc.) to get it right. This is why a lot of developers which aren't in unicorn startups take advantage of technology which is available from giants like Amazon or Google, or specific problem-domain companies like CloudFlare for example. Netflix serves as a great example of a technology-driven company that is an inspiration to us, but there are so many others that really changed the way we approach problems - Tumblr, Etsy. But to stay on topic of netflix - I think their idea behind "chaos monkey" is great, and we're increasingly rolling out a (currently simple) docker swarm version of it - https://github.com/titpetric/docker-chaos-monkey - the best way to eliminate worry is to test failure scenarios. As docker chaos monkey is designed to unpredictably "kill off" containers, your system gets the benefit of design to handle failures. It's one of those problems that you have to have a passion for however - it's like testing software. You're only testing software for the functionality and failures which you can predict, and I'm pretty sure that any of us can't predict all the ways in which software (or distributed systems) can fail. As such, it's a never ending occupation. :)

Because that wouldn't allow you to own a unicorn-size startup providing tools and technology for containerization?

Sometimes you have endpoint A and endpoint B.

They are part of the same app.

They should not have the same level of privilege.

The secrets in endpoint A's memory should not be visible to endpoint B and vice versa.

Containers increase assurance that this is so.

Databases have had table level privileges for decades. Not quite the same but its easy enough to use it for the same purpose.

I agree with you.

But if a single process has the single account on the database, how do you partition those permissions? Simply providing multiple logins won't help if you assume hostile code is in your process space.

On the other hand, if each service has its own login, then the database can enforce lowest authority for each. A compromise of one service isn't a game over scenario.

It's the difference between having a single account with the union of all permissions, or disjoint sets.

systemd can do the same thing. the only thing that docker adds or containers are immutability.

Cloud Foundry uses Garden which uses runC. But our Garden had a container system that predated docker and nspawn. So probably another case of Not Invented Yet Syndrome.