We could easily bring up a fleet of CoreOS instances, control it, feed it containers with unique IDs and IPs, make the containers do work (we did not exercise the containers), then shut them down, mostly with shell scripts rather than direct commands.
The suggested scripts serve as a template, and more templates are appearing, that allowed us to easily replicate functionality, so as to manage sprawl. If you're looking for instrumentation, get some glitzy UI elsewhere, and the same goes for high-vocabulary communications infrastructure.
Once you start adding daemons and widgetry, you're back to Ubuntu or RedHat.
And we warn that we could also make mistakes that were unrecoverable with equally high speed, and remind that there aren't any real safeguards except syntax checking, and the broad use of SSL keys.
You can make hundreds of OS instances, each with perhaps 100 Docker container apps all moving hopefully in a harmonious way. Crypt is used, which means you need your keys ready to submit to become su/root. Otherwise, you're on your own.
This is a skinny instance, bereft of frills and daemons-with-no-use. We found more memory and less potential for speed-slowing memory churn. Fewer widgets and daemonry also means a smaller attack surface. No bloat gives our engineer's instinctual desire to match resources with needs--no more and no less--more glee.
CoreOS largely means self-support, your own instrumentation, plentiful script building, and liberation from the pomposity and fatuousness of highly featured, general purpose, compute-engines.
Like to rough it? Want more real memory for actual instances? Don't mind a bit of heavy lifting? CoreOS might be for you.
Sign up for CIO Asia eNewsletters.