12 Factor: Apps for the Cloud

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

Transcript

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