On Active Deployment

I’ve watched the Kuby talk at Railsconf, and I have some opinions on Active Deployment. The talk attempts to provide a standard way of deploying Ruby on Rails using a cloud platform (Kubernetes). The talk also mentioned Capistrano and its still-relevant role in the community.

This left me with a question: if you plan to deploy a Rails application to production in 2022, are you now forced to use Kubernetes?

Over the years, I’ve been deploying Ruby on Rails applications on different types of infrastructure: virtual servers, managed platforms-as-a-service, and lately, Kubernetes clusters. Each type has its own strengths and weaknesses.

I think one way to help decide is how much resources in terms of skill, time, and money you can afford to spend on not just bringing up infrastructure but also sustaining its operation over time.

The talk mentioned several disadvantages of using Capistrano to deploy; one still needs to set up the software dependencies before successfully deploying a Rails application. I think this upfront cost is a valid trade-off in exchange for possibly cheaper operating costs (running a single server to run the whole stack versus provisioning multiple servers and running Kubernetes on top).

I’ve had two reasons to use Kubernetes in deploying a Rails application: (1) multitenancy, where multiple instances of the same application will be deployed, and (2) adopting a container-based delivery pipeline, which eliminates a whole class of problems (e.g., dependencies) in exchange for a different set of problems.

I wish that we keep our opinions on Active Deployment open. Not everyone needs a Kubernetes cluster to deploy, and there’s still value in keeping Capistrano around. There’s always a hosted platform, such as Heroku (and similar offerings), to ease the deployment burden for a price.