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

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

2. !=
+

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

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