As a former Google SRE, I'm pretty annoyed with the number of abstractions, indirections, and arbitrary features being pumped into docker. The core concept of Containers is supposed to be that you write to the unix process model, and the process model alone; Not create new systems from whole cloth in overly abstract ways.

This doesn't work for a lot of legacy systems, but rather than port or write new systems to do those functions, the Docker model seems to have absorbed all the hacks without documenting any of the best practices, allowing anyone who's going about creating new systems to wander off into the weeds of subfeatures and hacks.

Unfortunately, the LMCTFY project seems to be dead; They're porting features into the already bloated libcontainer, though I'm certain the borglet it is based on stays fairly pristine. LMCTFY and the google stack are a very different style of systems administration than is currently in vogue; but together they create a beautiful and pristine ecosystem with very few rough edges.

Anyway: If you want to know what you should be building with Docker, figure out how you would build it with just what LMCTFY provides. Some of it is non-obvious (Service discovery is a core service that exists in many forms, but few that are analogous/replacements for what the google stack needs), but by paring down what you work with, you ultimately create much tighter, more reliable systems.