Why buildpack when you can docker?
and vice versa
There’s an ongoing healthy debate at drie about a buildpack driven platform vs. one that accepts Dockerfiles.
The appeal of Dockerfiles is hard to ignore. You get to set up your container how ever you want, any operating system, any packages, but we believe the reality, while useful in some situations, isn’t that simple. Often Dockerfiles are used by developers because it allows them to rapidly develop on and deploy their applications to the same consistent operating system environment but what’s forgotten is ongoing maintenance of said OS. Like any OS your Docker images need constant attention, security alerts for packages and the regular patching that inevitably follows, an upgrade path, the packages need to be tested for good integration, etc. For a lot of very smart people managing this is a full time job and so shouldn’t be taken on lightly. And all of this applies to every docker image you deploy, which potentially means as many images as you have applications. You might get to a good place fast with a Dockerfile but you can quickly end up in a bad place if the images aren’t regularly maintained. Tools like Docker Security Scanner are certainly a step in the right direction but even tools like this still need regular interaction to be effective.
Buildpacks are a good separation of concerns. You focus on your application. Build it well, build it fast, you’ve got this. Someone (or really someone’s) equally enthusiastic about the language and framework you’ve chosen to use as you are about your application has written a buildpack for you. They’ve built it well because they’ve spent all their time doing that one thing and it’ll be battle tested by thousands of other users like you. Lastly people again equally as enthusiastic about operations around an application platform as you are about your application have created a deployment pipeline, a patching schedule, alerting, monitoring, scaling, and they’ve done it well because that’s what they’ve focused all their efforts on. It’s separating these concerns like this and sharing lower layers with an increasingly larger audience that’s made Linux and open source in general such a successful enterprise. Standing on the shoulders of giants lets you be the best and fastest you can at the layer you’re good at. In almost all cases buildpacks mean you can work on your application exactly as you would on your laptop and everything “just works” when you deploy it.
Even tho we like the idea of buildpacks we do also understand that sometimes your use case is truly unique, those giants just haven’t built the thing you need, and so you have no choice but to maintain an operating system to solve a problem. Next year we will be working on supporting Dockerfiles for these unique use cases and we’re keen to hear your suggestions for mitigating the OS maintenance dilemma that comes with them.
