> I've been pondering the implications of using Docker / Kubernetes to deploy a fairly complex application to production.<p>These systems are managed by dedicated <i>teams</i> most of the times. Kubernetes has many moving parts and debugging issues can be a nightmare.<p>Using docker is the way of the future. Docker merges development/production environments, facilitates CI/CD, simplifies deployments/rollbacks/etc., it even enforces <i>best practices</i> by separating layers (persistent vs ephemeral), so on and so forth.<p>You could deploy your application through ansible docker module on EC2 instances, droplets or what-have-you.<p>So the more subtle question is <i>why do you need an orchestrator?</i><p>Container orchestrators solve the problem of <i>density</i>. Say, my stack is made of services running in 128MB of RAM. I want to scale them quickly in and out on-demand.<p>If you don't have a density problem, e.g. your application will need 2GB of RAM anyway, I would say go with docker & EC2 autoscaling. Much easier to handle, you won't have to debug weird network/logging issues and all the problems that orchestrators bring along.<p>If you choose to go with an orchestrator, then for a small team, I would advice to take a look to Docker Swarm. Swarm comes with service discovery, load balancing, secrets & config-handling build-in. That's a big win for smaller teams. The learning curve is rather small, if you're already using docker. What you will have to handle if you go with swarm is:<p><pre><code> - Cluster initialisation (if you chose to automate this part, you might not, but you'd better automate the rest)
- Node-level autoscaling
- Container auto-scaling
- Dynamic routing (traefik or nginx + confd will solve this for you)
- Security (same goes for k8s or any other orchestrator, security requires eye for detail & experience)
</code></pre>
There are other minor issues (e.g. Swarm internal load balancer won't forward the real IP of the request to the internal service, which can be a PITA in some cases. There are workarounds mind you), but all orchestrators have minor issues and limitations.<p>Another word of caution about orchestrators: Most teams, don't need orchestration and don't have use cases that simpler setups cannot solve. Simple is smart, simple is genius. Keep it simple, until you can't keep <i>that</i> simple anymore.<p>Oh, don't even think about adding a persistent layer inside the orchestrator! If a service uses a Redis for caching for example, could be deployed as a <i>stack</i> in a swarm cluster. If you need persistence that goes beyond the lifecycle of the container, keep them out :-)<p>Good luck!