<p>I have a web application consisting of a few services - web, DB and a job queue/worker. I host everything on a single Google VM and my deployment process is very simple and naive:</p>

<ul>
<li>I manually install all services like the database on the VM </li>
<li>a bash script scheduled by crontab polls a remote git repository for changes every N minutes</li>
<li>if there were changes, it would simply restart all services using supervisord (job queue, web, etc)</li>
</ul>

<p>Now, I am starting a new web project where I enjoy using docker-compose for local development. However, I seem to suck in analysis paralysis deciding between available options for production deployment - I looked at Kubernetes, Swarm, docker-compose, container registries and etc.</p>

<p>I am looking for a recipe that will keep me productive with a single machine deployment. Ideally, I should be able to scale it to multiple machines when the time comes, but simplicity and staying frugal (one machine) is more important for now. I want to consider 2 options - when the VM already exists and when a new bare VM can be allocated specifically for this application.</p>

<p>I wonder if docker-compose is a reasonable choice for a simple web application. Do people use it in production and if so, how does the entire process look like from bare VM to rolling out an updated application? Do people use Kubernetes or Swarm for a simple single-machine deployment or is it an overkill?</p>

<blockquote>
  <p>I wonder if docker-compose is a reasonable choice for a simple web application.</p>
</blockquote>

<p>It can be, sure, if the development time is best spent focused on the web application and <em>less</em> on the non-web stuff such as the job queue and database. The other asterisk is whether the development environment works ok with hot-reloads or port-forwarding and that kind of jazz. I say it's a reasonable choice because 99% of the <strong>work</strong> of creating an application suitable for use in a clustered environment is the work of containerizing the application. So if the app already works under <code>docker-compose</code>, then it is with high likelihood that you can take the docker image that is constructed on behalf of <code>docker-compose</code> and roll it out to the cluster.</p>

<blockquote>
  <p>Do people use it in production</p>
</blockquote>

<p>I hope not; I am sure there are people who use <code>docker-compose</code> to run in production, just like there are people that use Windows batch files to deploy, but don't be that person.</p>

<blockquote>
  <p>Do people use Kubernetes or Swarm for a simple single-machine deployment or is it an overkill?</p>
</blockquote>

<p>Similarly, don't be a person that deploys the entire application on a single virtual machine or be mentally prepared for one failure to wipe out everything that you value. That's part of what clustering technologies are designed to protect against: one mistake taking down the entirety of the application, web, queuing, and persistence all in one fell swoop.</p>

<p>Now whether deploying kubernetes for your situation is "overkill" or not depends on whether you get benefit from the <em>other</em> things that kubernetes brings aside from mere scaling. We get benefit from developer empowerment, log aggregation, CPU and resource limits, the ability to take down one Node without introducing any drama, secrets management, configuration management, using a small number of Nodes for a large number of hosted applications (unlike creating a single virtual machine per deployed application because the deployments have no discipline over the placement of config file or ports or whatever). I can keep going, because kubernetes is truly magical; but, as many people will point out, it is not zero human cost to successfully run a cluster.</p>
