Docker is great for stateless apps like those that lie in the business logic tier of a Three-Tier Architecture system. These apps are like cattles. You can replace them easily when they die since it is supposed to be transient or ephemeral. Examples include RESTful services or static page apps.
As such, these are the implications when not to use Docker.
Do not use Docker if you don’t know the basics
If you don’t know the basics like shell scripting and a couple of Linux commands, you better learn it now starting with a virtual machine. I recommend Turnkey Linux since this is the most user-friendly Linux distro (read: integration with Shell in a Box and Webmin makes it especially usable for newbies).
As Matt Jaynes had said,
At the moment, you need more systems expertise to use Docker, not less.
Do not use Docker for stateful databases
As I have said above, Docker is useful for stateless apps at the business logic tier. That is why it is called immutable infrastructure. When your app needs to be updated, create a new image and throw the old one.
However, you cannot do that with SQL databases. This is why there are dozens of HA solutions out there. Where stateless apps are expected to be thrown away, stateful databases are expected to be always available.
Note that stateful databases are different from persistent data in data volumes in containers. Data volumes are supposed to be transient and needed only during the course of logic processing among containers.
See caveats for using MySQL as a container.
Do not use Docker if you need to run SSH
This is a hangover from those who are still adapting from the world of physical machines and physical servers. Since Docker containers reside on top of physical servers or virtual machines, use SSH on those Docker hosts, not on Docker containers.
As a result, you need to think in terms of microservices when using Docker. See Microservices – Not a Free Lunch.
Do not use Docker for macroservices
To reiterate on my point, Docker is useful for microservices (web services and cron tasks akin to Marathon and Chronos in Mesos).
When I say macroservices, I am referring to Big Data clusters usually with Apache on its name.
For Big Data clusters like Cassandra, Kafka, Spark and others, you ought to use Mesos but there’s no stopping you if you want to do it using Docker.
As others mentioned, Mesos is in some ways function as the opposite of virtualization.
Where Docker aims to reduce, reuse and recycle logic into containers, Mesos aims to consolidate physical resources into one big pool of logical resources.
The point of all this is for you to know when to use Docker and when not to.
You can Dockerize everything as containers but as always, there are caveats.