12 Factors of 12 Factor Apps
Back in the day, applications often went years between deployments. When deployments happened, it was an ugly, slow, and painful process that took a tremendous amount of time. Application management and diagnostic tools were limited and these limits were often imposed by the software itself, as most management functions were built into the app. It was even more annoying if you needed to spin up multiple copies of an application, move it to a different server, or change configuration information, as this information was scattered all over the place in a variety of formats, the application was probably dependent on locally installed tools and libraries, and the application wasn’t stateless. It was a nightmare (and still is for some of Will’s old employers). With the advent of cloud computing, we stopped treating servers like pets and started treating them like cattle. While this made it easier to quickly spin up infrastructure as we needed it, it also meant that certain old patterns of application development had to go away. In particular, we had to rework our applications so that their configuration information was stored in a predictable location, that application state was stored in a “saner” way, and so that processing could be interrupted at any time (because you never know when an admin is going to push a new configuration that will wipe out your runtime environment). It was a bit of adjustment, and many companies are still struggling with this to some degree. As things have gotten more complex, we’ve all had the urge to simplify our work. Not only does doing so make it easier to comprehend, it hopefully makes it easier to tell when we are doing something wrong. However, best practices always take a while to spread through the community and often are not platform agnostic at first. Thankfully, now we have some better general application guidelines that make it a lot cleaner and easier to develop cloud-native, modern applications that play nicely with modern devops tools, especially tools built around orchestration, deployment, logging, and storage. 12 factor applications are a set of best practices that make it much easier and less risky to deploy and manage applications on modern cloud infrastructure. In addition to this lowered risk, they also make it easier to deploy applications continuously, by limiting the variance between development and deployed versions of the application. Finally, they also offer industry standard ways of dealing with cross-cutting concerns, like logging, configuration, and process management with good tooling, rather than stuff you cobbled together in house. Episode Breakdown The Codebase 12 factor apps are always tracked in version control in a one-to-one correlation between the codebase and the app. Use shared libraries instead of multiple apps in the same codebase. While there is only one app per codebase, there can be many deployments of the same app. Codebases are the same across all deployments, but different versions may be active in each deployment. This makes it easier for anyone on the team to make changes and redeploy the application, without worrying that someone deployed directly from their machine. Dependencies Explicitly declare and isolate dependencies. Do not implicitly rely on things being installed on the system. The declaration of dependencies will be accomplished via a manifest and will use a dependency isolation tool to make sure that implicit dependencies don’t leak in from the surrounding system. This also includes system tools, like curl and other commandline tools. If these are used, they need to be explicitly listed. This makes it easier to set up a new environment for new developers, or to determine if a vulnerability that just hit the news is a problem for your application. Config