12 Factor: Apps for the Cloud

12 Factor: Apps for the Cloud

An overview of 12-factor applications, based on 12factor.net


Davey Shafik

June 16, 2015


  1. Twelve Factor: Apps for the Cloud

  2. Proprietary and Confidential •Community Engineer at Engine Yard •Author of

    Zend PHP 5 Certification Study Guide, Sitepoints PHP Anthology: 101 Essential Tips, Tricks & Hacks & PHP Master: Write Cutting Edge Code •A contributor to Zend Framework 1 & 2, phpdoc, & PHP internals • Original creator of PHAR/PHP_Archive •@dshafik Davey Shafik
  3. Let’s start a conversation about mental health in tech mhprompt.org

  4. What is 12 Factor?

  5. From the fine folks at

  6. • Declarative Setup and Configuration • Clean Contracts Between Services

    • Scalability • Minimal Divergence Between Environments 12 Factor Apps
  7. • Easy to Deploy Anywhere • Easy to Scale •

    Easy to Maintain • Easy to Develop Put Another Way…
  8. Shared Nothing

  9. • Any time you share resources, scaling is hard •

    Shared Nothing tries to eliminate any shared resources • At worst, it puts shared resources in appropriate, easily scaled data stores – e.g. sessions in memcached, search in ElasticSearch Shared Nothing
  10. 1. Codebase

  11. Ƙ Codebase Dev Staging QA Production Deploys

  12. • One codebase, many deployments – Dev, Staging, QA, Production

    • Multiple codebases = distributed system • Shared code should be in re-usable libraries • Micro-services architecture good – Each service must itself adhere to 12-factor! • Environments should be functionally identical 1. Codebase
  13. 2. Dependencies

  14. • Never rely on system-wide packages (e.g. gems) • Always

    vendor dependencies, including system tools (e.g. imagick) • Lock files are your friend • Package Managers: – Ruby: bundler – PHP: composer – Node.js: npm – Python: pip 2. Dependencies
  15. 3. Config

  16. • Configuration is variables that will change between deployments (dev/

    qa/staging/prod) – Database credentials – Service credentials – Service locations • Stored in Environment Variables – Language/OS agnostic – Easy to change – You won’t accidentally commit things like passwords into RCS 3. Config
  17. 4. Backing Services

  18.    Production Database Amazon S3 Twitter

  19. • All resources are treated as services • Treat local

    and third-party services identically • All resources should be accessed via an API, making them an implementation detail that can be switched out • Service Locations and Credentials stored in the shared config 4. Backing Services
  20. 5. Build, Release, Run

  21. Ƙ Codebase Build Config + Release =

  22. • The Build performs tasks to create a distributable version

    of the code base – Bundle dependencies – Compiles binaries – Builds assets • The Release combines the Build with the Config • The Run is the actual execution of the release in it’s intended environment 5. Build, Release, Run
  23. 6. Processes

  24. • Execute the app as one or more stateless processes

    • Any data that needs to persist must be stored in a stateful backing service • Memory and local FS may be used as a brief, single transaction cache (such as handling large files) • Dependencies are incorporated during the build, rather than on deploy • Sticky sessions are a violation of 12-factor. Use a shared session store. 6. Processes
  25. 7. Port Binding

  26. • All applications should expose themselves via userland HTTP •

    This allows for a completely self-contained application • I strongly disagree with this! • Great for dev, often terrible for production (particularly in PHP) • Doesn’t work with middle-ware type stacks, like WSGI and PSR-7 7. Port Binding
  27. 8. Concurrency

  28. processor.1 translator.1 web.1 web.2 processor.2 translator.1 translator.2 translator.3 translator.4 Scale

    (running processes) Workload Diversity (process types) web.3
  29. • Applications should scale by spawning more processes • This

    enables easy horizontal scaling • Shared-nothing makes this easy • By using micro services and different process types we can easily scale different workloads with different resource needs 8. Concurrency
  30. 9. Disposability

  31. • All processes should be disposable — this helps with

    rapid deployment • All processes should gracefully handle SIGTERM (e.g. return job to the queue) • Handling of unexpected death should be handled when possible • All jobs should ideally be idempotent, and must be reentrant — running them again after death should be possible • Processes should minimize startup time 9. Disposability
  32. 10. Dev/Production Parity

  33. • Minimize differences between development and production environments – Time:

    Quick deploys ensures that the codebases diverge minimally – Personnel: Code authors should also be deploying it – Tools: Use the same tools in both systems, do not use lightweight alternatives (e.g. SQLite) or different OSes (use a VM if necessary) 10. Dev/Production Parity
  34. 11. Logs

  35. • Logs should be treated as an event stream •

    All processes should emit logs to STDOUT • During development, a developer should have these visible in the foreground • In other deploys the environment is responsible for collating these all together into a single cohesive event stream • Routed to one or more final destinations (file, network storage, splunk) 11. Logs
  36. 12. Admin Processes

  37. • Admin and management processes (such as DB migrations) should

    be run as one-off processes. • Run in a duplicate environment with the same config (so that it points to the same data sources) • Run against a specific release • Admin processes must ship the release code alongside to avoid sync issues 12. Admin Processes