@paulbecotte @kellabyte Note that baseimage-docker is not about running multiple services in the same container. We encourage running multiple processes in one container if it makes sense, e.g. if a single service naturally consists of multiple processes. We're not necessarily advocating that you should run all your services in the same container (although we made it possible for you to do that, if you wish to do so or if you have a legit use case for it). Processes != services.
For example, Nginx consists of multiple processes: it consists of a master process that delegates work to a number of worker processes. Or PostgreSQL, which has a process for the query planner, a process for buffer management, etc. In both cases it wouldn't make sense to run each process in its own container because all of these processes are designed to work together as a whole.
As an extension of this idea, consider some app, one which is outside your control, that natively logs to syslog. You don't want its logs to be be redirected to /dev/null -- you want its logs to be redirected to the Docker logs. This syslog-to-Docker-logs redirection can be thought of as a natural part of the logical service, so in this case it would make sense to run the syslog daemon inside the same container.
But let's say you're making a web app. Should you run the database server in the same container? Depends: there is a lot to be said for separating the database to another container, and baseimage-docker does not force any particular philosophy on this case. It's up to you to decide really, and there is not one answer. For example, in some use cases the added usability benefits (for end users) of running the database in the same container might be worth it. But unlike Docker inc who seems to say "nooo!! always run everything in its own container", we take the more moderate stance of "think about this, the choice is up to you as long as you make a well-reasoned choice and understand its implications".