This is part of a miniseries explaining what I am working on lately: Porter which is based on the Cloud Native Application Bundle, or CNAB Specification. Start from the beginning
Clouds kinda suck. Don’t get me wrong. I like them because I don’t have to beg someone in IT to provision a database, load balancer, static IP or virtual machine. However the complexity and knowledge required to deploy software has really increased over the years and clouds have had a bit to do with it.
I can deploy my code ANYWHERE. Emphasis on me deploying that code, not some beleaguered ops person, hidden away in the company’s “on-premise data center” cough closet cough. There are a lot of great tools out there that let me pretend that I’m doing devops: Kubernetes, Helm, Terraform, [insert 500 more tools here].
Any one of those tools does a pretty good job in their own domain. But I never have the luxury of learning and dealing with just one of them. I’m always gluing together my cloud provider’s CLI, Kubernetes, Helm, whatever I could find that is giving me Let’s Encrypt SSL certificates, lots of awkward glue scripts to hack together configuration, secret management, persistent storage and jeez I still haven’t even mentioned my own application yet have I? Really that’s the only thing I wanted to deal with in the first place… 🤦♀️
This is the problem that CNAB wants to solve
How do we make it easier to manage everything it takes to install, upgrade, uninstall and generally operate an application? When I say everything I’m referring to:
- Tools that you need installed on your laptop or in your production environment
before you can even begin, like
helm
,terraform
,az
, orkubectl
. - Helm charts, and yaml files.
- Bash scripts for each environment.
- Various configuration files, parameters and credentials.
- Collections of docker images with knowledge of what volumes need to be mounted, environment variables set and commands run when you start them.
- Logic to manage all the infrastructure on which the application runs.
A Cloud Native Application Bundle (CNAB) is something that wraps up all
of this so that someone can install an application on a cloud, from scratch with
nothing else on their machine but porter and docker, with just one command
porter install myapp
. They didn’t need to make a cluster, download kubectl or
helm, figure out the right helm chart, or write any bash to connect it all
together.
Just like a Docker image is an application all packaged up, a bundle is the application and all the tooling + logic to provision the infrastructure underneath it.
The CNAB specification is just enough agreement between a bunch of big companies to make sure that bundles made by Docker or Pivotal or Microsoft work with each other’s tools. It is concerned with how to execute a bundle, but not how to author a bundle. CNAB is about the runtime.
What problem does Porter solve?
Porter makes authoring bundles easier
- Pragmatic
Cannot require migrations from existing tools or being the only tool in the ecosystem. - Composable
Compose bundles using other bundles. - Respectful
Respect people’s time. Do not require them to know the CNAB spec. Must yield a quality, maintainable bundle with low investment of time.
It’s worth saying that Porter isn’t yet another configuration management tool. It doesn’t replace any existing tool out there. If you already have a bunch of helm charts, terraform configuration files, or even bash scripts, then that’s what you should keep using when you make a bundle.
How does Porter help author bundles?
Free Glue Code
Porter is the glue code to do few things:
- Build a bundle and have it execute an ordered set of tasks.
- Use existing tools in bundles. Porter has mixins that adapts these tools to CNAB.
- Connect inputs and outputs between tools that were never made to work together, like Helm and the Azure CLI. For example, if your bundle uses Azure to create a managed database, and then Helm to deploy Wordpress, Porter handles the extracting the database connection string from the Azure mixin and injecting it into the Helm mixin.
Developer Experience
Porter doesn’t just make authoring bundles easier. Porter is designed to have the best developer experience for working with bundles, full stop.
Those that know me, know that I care about the user experience more than shiny
technical solutions. Since I’m the creator, tech lead, project manager and chief
emoji officer of Porter, that means that the GitHub label that carries the most
weight in my repo is user experience 🌈💖
.
I think that’s a problem worth solving too.
Yay! You’re all caught up and now I can finally tell you about the MEGA RELASE OF DOOM that triggered this deluge of blog posts.