12 FACTOR APPS GOOD PRACTICES FOR SAAS DEVELOPMENT By , 12factor.net translator (pt_br) Luiz Filho 

VERTICAL X HORIZONTAL SCALING 12 Factors thinks horizontally (great for our Cloud and Container based times!) 

_AAS 

12FACTOR.NET 12 Factor App Manifesto 

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 

FACTOR I - CODEBASE One code base, many deploys 

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 

FACTOR II - DEPENDENCIES Example - Node.js: Dependency manifest = package.json Isolation tool = npm install "socket.io": "~1.3.7" 

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?" 

FACTOR IV - BACKING SERVICES No local and 3rd party difference 

FACTOR V - BUILD, RELEASE, RUN Strictly separate build and run stages BUILD = codebase + dependencieis + assets RELEASE = BUILD + config RUNTIME = run process against RELEASE 

All modification generates a new unique release All transformations are one-way Ability to rollback 

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 

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 

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 

No content

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 

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 

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) 

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...) 

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 

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) 

THE END Official site: Other slides: Me again: 12factor.net 12 Factor App - Best Practices for JVM Deployment luiz.in