Just What is a “12 Factor App”?
If you haven’t heard of the 12 Factor App, you probably will soon. You can think of it as almost as the agile manifesto for DevOps. (The comparison isn’t perfect, but I’ll stop making it as soon as we can reliably define DevOps.) You will feel a bit smarter if you can understand the basics, whether a developer, DevOps-er, manager, or analyst.
First, the back-story…
Adam Wiggins of Heroku wrote the short eBook published at 12Factor.net. If you aren’t familiar with Heroku, they are a leading Platform as a Service company that has automated and streamlined cloud application deployments, and are leaders in the space. Therefore, to the extent Heroku has opinions about DevOps and building apps for the cloud, you should listen.
In buzzword speak, the 12 Factor App can be translated as: 12 key DevOps-related things to make your SaaS application well-suited for deployment to the cloud (presumably to apply machine learning to noSQL big data).
But why? Livestock. That’s why.
In the world of cloud infrastructure, we treat servers like livestock, not pets.
Pets require special care and feeding. We name them. We get attached to them. We try to prolong their lives. This is a problem (for servers that is… go on treating your pets kindly). Particularly in a cloud environment, we cannot count on knowing where our server is, counting on local hard drive storage, knowing where the database is, or taking comfort that it won’t die today.
Servers should be treated like livestock. We number the build. Once the build has served it’s purpose, it becomes mutton, and we start fresh with a new build. This is particularly critical in the world of orchestrated chaos that is a modern cloud infrastructure. Servers are spawned, live, and die for a variety of reasons: responding to scaling needs, applying patches, upgrading the app, or coping with an AWS engineer typing a command.
What about these 12 factors?
The 12 Factors are, frankly, pretty in-the-weeds, and best detailed in The 12 Factor App. It is perhaps more akin to the Scrum agile framework than the agile manifesto — i.e. prescriptive low-level implementation vs. principles.
However, I’d like to add on what may be the missing context. What is great about the Agile Manifesto is that it starts with high-level principles. My take at the principles driving the 12 Factor App are:
- You can easily recreate and start up the app from scratch.
(I. Codebase; III. Config; V. Build, release, run; X. Dev/prod parity) - You can gracefully kill your app.
(VI. Processes; IX. Disposability) - You can gracefully scale your app.
(VI. Processes; VIII. Concurrency; XI. Logs; XII. Admin processes) - Technical plumbing is based on cloud assumptions.
(III. Config; IV. Backing services; VII. Port Binding; XI. Logs)
Is this useful?
Yes. The 12 Factors are basically a checklist to answer the question: is my app ready for cloud deployment? We’ve used the 12 Factor App as an organizing tool to develop simple scorecards for sets of applications — and most critically, to identify the set of tasks to close any gaps.
The more you know…
There you have it. You are now just smart enough to talk about the 12 Factor App! Obviously, reading the source docs is the best way to actually get smart.
Also, I gave a talk on this topic at AgileDC 2017, and the slides are available.
