12 Factor Applications

The 12 Factor “manifesto” was written by Adam Wiggins back in 2012 and has become something of a template for building scalable, modern applications in the RESTful era. Find out how it can help you write simple, scalable software for the modern age.

12 Factor Applications

Turns out I’d been doing a lot of the aspects anyway, but having a structure that builds towards the whole identified a few missing pieces that strengthened the system.

Core Theory

The central point behind 12 Factor is that application definition and deployment should be clean, easy to understand, repeatable, and structured in such a way as to avoid the vast majority of problems that contemporary server-side applications run into regularly.

It's Not for Everyone

If you’re building the next GMail or Netflix then this approach may not be best for you.  I say “may not be” instead of “isn’t” because even in those situations, this method could help you.  In the interests of time, I’ll offer a quick metric - if you have more than $100M in VC funding to build your platform, probably stop reading here.  For the rest of us, 12 Factor gives us an approach solidly grounded in pragmatic development that will usually work better than the alternatives, with very few real-world downsides.

It Is for You?

Still with me?  Good.  This system may not be sexy, trendy, or show up in a lot of TEDx talks, but it has one very simple advantage - it works. Small, nimble teams can use these practices to deliver software more consistently, on time, and on budget.  Larger teams can usually brute-force their way through the difficulties that ignoring them creates, but by embracing them will free up resources to do what they’re supposed to be doing, write code that solves business problems and creates revenue.

IMHO…

In this series I will also be adding my commentary along the way.  I generally agree with all of the principles, but there are times where I take issue with some specifics. Having said that, whenever you come across a coherent set of principles you’re almost always better off following them systemically than picking and choosing.  Its not always obvious when one principle feeds into another, and skipping something that seems inconsequential can have unexpected consequences down the line.

Let's Explore

  1. Codebase
  2. Dependencies
  3. Config
  4. Backing Services
  5. Build, Release, Run
  6. Processes
  7. Port Binding
  8. Concurrency
  9. Disposability
  10. Dev/Prod Parity
  11. Logs
  12. Admin Processes