Let's talk about application buildpacks
- 1 minIn micro/nano service development every service should have it’s own pipeline and be independently deployable. In this world the source code repository would have a pipeline definitions, deployment template (Helm chart or deploy.sh), definitions of the application runtime (Dockerfile) and maybe some ignore files and security policies files (e.g. exclusions).
Defining these components for every service source control is tiresome, difficult to update, govern centrally and does not scale when templates need to be changed. You could argue if you defined this centrally your services are not decoupled from one another, but in order to scale you need shared assets and templates.
How could you achieve this? Well, buildpacks (not new, been around a while e.g. Heroku, CloudFoundry, Gitlab CI). Buildpacks groups these common components together to enable an application to be deployed and run. Buildpacks are defined for various technologies (Java, JavaScript, Go).
But who owns these buildpacks? Well, you might have a SRE team responsible for running applications and defining central buildpacks. But you’re abstracting the mechanics away from the developers, yes it is a trade off but nothing stops them developing the build packs they just need to be centrally catalogued and governed.
How might you implement build packs? That’s for another post.
Additional resources:
- https://buildpacks.io/#learn-more
~Robert