Buzzwords are the result of our need to build a shared language that allows us to communicate about complex topics without having to stop and do a review. Shared terminology isn’t just convenient, it’s essential for decision making, architecture design, debates, and even just friendly discussion.
The Twelve-Factor Application is one of these phrases that is gaining traction and is being passed around during planning meetings, discussions over coffee, and architecture review sessions.
The problem with shared context and common language like buzzwords is that not everyone has the same understanding. Twelve-Factor to one person might mean something entirely different to someone else, and many readers of this book might not have any exposure to the 12 factors.
The goal of this book is to provide detail on what exactly Twelve-Factor applications are so that hopefully everyone who has read the book shares the same understanding of the factors. Additionally, this book aims to take you beyond the 12 factors, expanding on the original guidelines to accommodate modern thinking on building applications that don’t just function in the cloud, but thrive.
The Original 12 Factors
In the early days of the cloud, startups appeared that offered something with which few developers or companies had any experience. It was a new level of abstraction that offered IT professionals freedom from a whole category of nonfunctional requirements. To some, this was a dark and scary frontier. Others embraced this new frontier as if all of their prayers had been answered.
One of the early pioneers laying claim to territory in the public cloud market was Heroku. It offered to host your application for you, and all you had to do was build your application and push it via git, and then the cloud took over, and your application magically worked online.
Heroku’s promise was that you no longer even needed to worry about infrastructure; all you had to do was build your application in a way that took advantage of the cloud, and everything would be just fine.
The problem was that most people simply had no idea how to build applications in a way that was “cloud friendly.” As I will discuss throughout this book, cloud-friendly applications don’t just run in the cloud; they embrace elastic scalability, ephemeral filesystems, statelessness, and treating everything as a service. Applications built this way can scale and deploy rapidly, allowing their development teams to add new features and react quickly to market changes.
Many of the cloud anti-patterns still being made today will be discussed throughout this book. Early adopters didn’t know what you could and could not do with clouds, nor did they know the design and architecture considerations that went into building an application destined for the cloud. This was a new breed of application, one for which few people had a frame of reference.
To solve this problem (and to increase their own platform adoption), a group of people within Heroku developed the 12 Factors in 2012. This is essentially a manifesto describing the rules and guidelines that needed to be followed to build a cloud-native1 application.
The goal of these 12 factors was to teach developers how to build cloud-ready applications that had declarative formats for automation and setup, had a clean contract with the underlying operating system, and were dynamically scalable.
These 12 factors were used as guidelines to help steer development of new applications, as well as to create a scorecard with which to measure existing applications and their suitability for the cloud:
- One codebase tracked in revision control, many deploys
- Explicitly declare and isolate dependencies
- Store configuration in the environment
- Backing Services
- Treat backing services as attached resources
- Build, release, run
- Strictly separate build and run stages
- Execute the app as one or more stateless processes
- Port binding
- Export services via port binding
- Scale out via the process model
- Maximize robustness with fast startup and graceful shutdown
- Dev/prod parity
- Keep development, staging, and production as similar as possible
- Treat logs as event streams
- Admin processes
- Run admin/management tasks as one-off processes
These factors serve as an excellent introduction to the discipline of building and deploying applications in the cloud and preparing teams for the rigor necessary to build a production pipeline around elastically scaling applications. However, technology has advanced since their original creation, and in some situations, it is necessary to elaborate on the initial guidelines as well as add new guidelines designed to meet modern standards for application development.
Beyond the Twelve-Factor Application
In this book, I present a new set of guidelines that builds on the original 12 factors. In some cases, I have changed the order of the factor, indicating a deliberate sense of priority. In other cases, I have added factors such as telemetry, security, and the concept of “API first,” that should be considerations for any application that will be running in the cloud. In addition, I may add caveats or exceptions to the original factors that reflect today’s best practices.
Taking into account the changes in priority order, definition, and additions, this book describes the following facets of cloud-native applications:
- One codebase, one application
- API first
- Dependency management
- Design, build, release, and run
- Configuration, credentials, and code
- Backing services
- Environment parity
- Administrative processes
- Port binding
- Stateless processes
- Authentication and authorization
12factor.net provided an excellent starting point, a yardstick to measure applications along an axis of cloud suitability. As you will see throughout the book, these factors often feed each other. Properly following one factor makes it easier to follow another, and so on, throughout a virtuous cycle. Once people get caught up in this cycle, they often wonder how they ever built applications any other way.
Whether you are developing a brand new application without the burden of a single line of legacy code or you are analyzing an enterprise portfolio with hundreds of legacy applications, this book will give you the guidance you need to get ready for developing cloud-native applications.
1 For many people, cloud native and 12 factor are synonymous. One of the goals of this book is to illustrate that there is more to being cloud native than just adhering to the original 12 factors. In Heroku’s case, cloud native really meant “works well on Heroku.”