12 steps to devops nirvana

Text

12 Steps to DevOps NirvanaBhavin Javia @bhavinjavia Founder @

!=

+

- by Adam Wiggins

http://12factor.net

co-founder

What ismethodology 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. CodebaseTracked 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. DependenciesNever rely on system-wide packages

Dependency declaration & Dependency isolation

Use tools for both

Simplifies setup for new devs

Vendored system tools (controversial)

III. ConfigAnything 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 ServicesAny 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, runStrictly 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. ProcessesOne 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 bindingExport services via port binding

App binds to HTTP port

Most server software can use port binding

One app == backing service for another

VIII. ConcurrencyScale 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. DisposabilityProcesses 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. LogsLogs == 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 processesRun 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

bhavin@mavenhive.inhttps://speakerdeck.com/bhavinjavia http://www.slideshare.net/bhavinjavia