12 Steps to DevOps Nirvana

My ignite talk at DevOpsDays India 2013 devopsdays.org/events/2013-india/

Transcript

1. Text 12 Steps to DevOps Nirvana Bhavin Javia @bhavinjavia Founder @
2. != +
3. - by Adam Wiggins http://12factor.net co-founder
4. 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
5. Who should read ? Devs building SaaS apps Ops engineers managing SaaS apps Apps written in any programming language Apps deployed on the cloud
6. 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
7. 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)
8. 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)
9. 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
10. 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
11. 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)
12. 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
13. 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
14. IX. Disposability Processes are disposable Minimize startup time Shut down gracefully Should handle hardware failure Return jobs back to the queue on failures
15. 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
16. 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
17. 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
18. Is it for me ? These are broad, conceptual guidelines You might have Env specific differences Organizational constraints Infrastructural constraints YMMV
19. See what works
20. Thank You @bhavinjavia bhavin@mavenhive.in https://speakerdeck.com/bhavinjavia http://www.slideshare.net/bhavinjavia