Totally agree, Aaron.

Good point, Michael. The system, I’m describing is similar to a PaaS approach.

I worked on a PaaS for Kubernetes (Deis Workflow) and have seen the pros and cons of the approach. Folks loved — and still love — Workflow because it makes things so simple.

I purposefully didn’t mention the word because I want to convey that this thing doesn’t ship with limitations that other PaaS-es do. Out of the box, it abstracts aggressively, but it has escape hatches. If you don’t buy into the opinionated approach, simply sidestep the abstractions. But know that some of the tools won’t work properly if you do.

Buffalo — a framework for building Go webapps — takes a similar stance. As does Ruby on Rails.

A Simple Example

Many PaaS-es reach all the way down into your code, build it for you (buildpacks), and then get it into production. This system assumes you already know how to build your code — and even build a Docker image out of your artifacts.

If you want to add buildpacks to the system, build a service in Kubernetes that you send your code to. You’re responsible for the client-server RPC, storing the Docker image somewhere, and then calling system deploy $MY_IMAGE. Draft does something like this now.

The Bottom Line

The key point I’m making here is that the system covers common workloads. You could call it a PaaS because it looks like one out of the box, and that’s what newcomers need.

But it grows too. You can swap out the templating engine in Rails but you won’t figure that out on day 1. Similarly, you can opt into Kubernetes primitives as you need; but again, you have to know what you’re doing.