12 Factor Apps

[Recorded presentation (Portuguese): https://www.youtube.com/watch?v=pPO13av5jsM ]

An overview of 12 Factor Apps (12factor.net) - Guidelines for SaaS development.

Transcript

1. 12 FACTOR APPS GOOD PRACTICES FOR SAAS DEVELOPMENT By , 12factor.net translator (pt_br) Luiz Filho
2. VERTICAL X HORIZONTAL SCALING 12 Factors thinks horizontally (great for our Cloud and Container based times!)
3. _AAS
4. 12FACTOR.NET 12 Factor App Manifesto
5. WHAT'S IN IT FOR ME? Solutions to these common pain points: Swarm of new apps everyday, with... Limited scalability Tangled, unclear, spread dependencies Need a rewrite to scale easily Different patterns and practices for different projects, environments, languages
6. FACTOR I - CODEBASE One code base, many deploys
7. FACTOR II - DEPENDENCIES Explicitly declare and isolate Declare dependencies in a manifest Use isolation tools Specific versions are important Avoid shelling to unbundled system tools
8. FACTOR II - DEPENDENCIES Example - Node.js: Dependency manifest = package.json Isolation tool = npm install "socket.io": "~1.3.7"
9. FACTOR III - CONFIG Store in the environment It's the specific info to run a deployment of a codebase Ex: database credentials, paths, resource urls, etc Keep it outside the app Don't version control it Real world test: "can you make it open source right now?"
10. FACTOR IV - BACKING SERVICES No local and 3rd party difference
11. FACTOR V - BUILD, RELEASE, RUN Strictly separate build and run stages BUILD = codebase + dependencieis + assets RELEASE = BUILD + config RUNTIME = run process against RELEASE
12. All modification generates a new unique release All transformations are one-way Ability to rollback
13. FACTOR VI - PROCESSES Execute the app as one or more stateless processes Runs the release Shares nothing with other processes Asset compilation at build time
14. FACTOR VII - PORT BINDING Export services via port binding The 12 factor app is completely self-contained The contract with the execution environment is binding to a port, and only that This means that one app can become the backing service for another app
15. FACTOR VIII - CONCURRENCY Scale out via the process model The need for scaling out... Scale out via processes, unix style Different processes types (web, db, worker) Processes don't daemonize nor write PID's Trust system's process manager
17. FACTOR IX - DISPOSABILITY Maximize robustness with fast startup and graceful shutdown Rapid deployment of new changes Start quickly More agility to scaling up Process Manager can more easily move processes to new machines
18. Shut down gracefully. E.g: Cease listening on its port (refuse new requests) Web: allow current requests to finish Worker: return current job to queue Be robust against sudden death
19. FACTOR X - DEV/PROD PARITY Keep dev, staging, and prod as similar as possible There are usually some gaps between dev and prod: Temporal (days to prod after dev) Personnel (dev & ops) Tooling (DB's, SO's, VM's, etc)
20. We gotta shorten those gaps for Continuous Deployment CI && deploy ASAP after coding Get Devs involved in Operations Envs must be as similar as possible Resist the urge to use different backing services in dev machines. (Tip: Docker, Vagrant, Otto, Puppet, Chef, Ansible...)
21. FACTOR XI - LOGS Treat logs as event streams Don't route or store logs in files Stream to stdout and let the env capture and handle it Tip: structured log
22. FACTOR XII - ADMIN PROCESSES Run admin/management tasks as one-off processes Eg: Database migrations Console / REPL One-time scripts Run as a separate process From same codebase/release (same dependencies, isolation, etc)
23. THE END Official site: Other slides: Me again: 12factor.net 12 Factor App - Best Practices for JVM Deployment luiz.in