Text 12 Steps to DevOps Nirvana Bhavin Javia @bhavinjavia Founder @ 

!= + 

- by Adam Wiggins http://12factor.net co-founder 

What is methodology to build SaaS apps triangulation of best practices development, deployment, scaling of 100,000s of apps organic growth, collaboration, avoid software erosion awareness, shared vocabulary, conceptual solutions 

Who should read ? Devs building SaaS apps Ops engineers managing SaaS apps Apps written in any programming language Apps deployed on the cloud 

I. Codebase Tracked in version control One codebase per app Many deploys Same codebase, different versions Mutiple apps == Multiple Codebases (and Apps) Extract Libraries to share code 

II. Dependencies Never rely on system-wide packages Dependency declaration & Dependency isolation Use tools for both Simplifies setup for new devs Vendored system tools (controversial) 

III. Config Anything that varies across deployments Except internal app config Strictly separate config from code Litmus Test: Can you open source it RIGHT NOW ? Store config in Files (good) or ENV vars (better) Grouping of ENV vars (does not scale) 

IV. Backing Services Any services consumed over the network Attached resources No distinction b/w Local & Third Party services Service == Resource Resources attached or detached at will 

V. Build, release, run Strictly separate stages 1. Build Convert code to executable ‘build’ Can be complex 2. Release Combine build & config Immutable 3. Run run the release keep it simple 

VI. Processes One or more processes Stateless and share-nothing Process Memory/FS == transactional cache Store persistent data in stateful backing storage No sticky sessions (controversial) 

VII. Port binding Export services via port binding App binds to HTTP port Most server software can use port binding One app == backing service for another 

VIII. Concurrency Scale out via process model Scale == Running Processes Workload Diversity = Process Types Does not exclude internal threads, evented model Adding concurrency is simple and reliable Never daemonize and use a Process Manager 

IX. Disposability Processes are disposable Minimize startup time Shut down gracefully Should handle hardware failure Return jobs back to the queue on failures 

X. Dev/prod parity Keep Dev, Staging, Production similar Reduce gaps in Time, Personnel and Tools Design for Continuous Deployment Mind parity issues in Backing Services Lightweight, local services less compelling Use same type & version of backing services 

XI. Logs Logs == Event streams Provide visibility into running app App not concerned about routing/storage Route all logs to single destination Index and analyse logs for Find past events Graphing of trends Alerting 

XII. Admin processes Run admin tasks as one-off processes DB migrations REPL shell One-time scripts Run Admin process in identical env Run against same release Ship admin code with app code 

Is it for me ? These are broad, conceptual guidelines You might have Env specific differences Organizational constraints Infrastructural constraints YMMV 

See what works 

Thank You @bhavinjavia [email protected] https://speakerdeck.com/bhavinjavia http://www.slideshare.net/bhavinjavia