It’s easy to make the most popular choice, but the popular choice isn’t always the most correct. Sometimes you have to step out on a limb.
Google’s Kubernetes (“k8s”) is vastly more popular than Docker Swarm, but k8s was developed by Google for themselves… i.e. for Google-sized workloads. Certainly it can no doubt easily handle City of Chattanooga-sized workloads, but – for now – we opted to orchestrate our container network with Docker’s own Swarm.
The number one reason for Docker Swarm is the fact that it’s Docker… meaning most of what one learns in order to use Docker as, say, a developer, ports easily into the Swarm deployment process. For a small team that has to cover all the bases, grey matter is a precious resource! Using k8s to orchestrate Docker containers means double the things we have to learn and remember… and also increases our chances of getting burned by those inevitable things that we don’t know we don’t know.
Add to this that Docker Swarm is smaller and more nimble (and yet can handle way more containers than we’ll ever need). Of course there’s no reason why we can’t move into k8s later if we choose… a process that will be easier with everything in MyChattanooga already container-based.
Finally, my own experience – fairly extensive at this point – has been with Docker Swarm. I’ve been through many successes and a handful of failures (some more dramatic than others!) with Swarm and am better prepared to carve out an environment for MyChattanooga using it.
Thus, on 29 May, the MyChattanooga cluster blazed to life, and we’ve been using it for testing and development over the past couple of weeks. We’re pretty excited to be officially moving into the world of production containerization and, as it will be for so many other things, the MyChattanooga project is leading the way.