12 Factor Apps for Operations

rags srinivas (@ragss)matt cowger (@mcowger)

#1: Codebase• Everything in revision control

• Including environment configuration

I didn't change anything!— every. developer. ever.

Well the environment didn't change!

— every. ops. person. ever.

Revision Control -> git blame

(svn blame if you must)

#2: Dependencies• Dependencies must be explicitly declared

• They should be declared with the rest of the code, and tracked the same way

• Dependencies tracking should contain version numbers of dependencies

#3: Config• Config belongs in the environment if possible - it varies

between deploys, but the code doesn't

• Includes access credentials, logging config, etc.

• Should be read at runtime, not preprocessed into code.

• Only people with access to host & account can see creds

• Creds can be specific (maybe avoid shared accounts!)

• Now everyone knows the live config, all the time, and be sure code is using it.

• Less danger of having critical file stolen/checked in

#4: Backing Services• Anything your application uses as a resource (database,

queueing system, email, cache) should be referenced with 'bindings' to these services.

• All applications deployed with explicit declarative references ( as in manifest.yml)

• Avoid implicit references (User Provided Services)

#5: Build Release Run• Build, Release and Run are separate stages for the

application life cycle.

• Version everything

• Use profiles

• Blue/Green Deployments are a rule, not an exception.

#6: Processes• Seperation of concerns - each microservice is a single

process

• Instances of running code to be stateless - certain exceptions apply

• This makes apps more resilient, and easier to recover

• Categorize processes into Stateful and Stateless

#7: Port Binding• Export services via port binding

• For instance HTTP is exported as a service via port binding and not injected at run time.

• The ultimate goal is to be able to horizontally scale.

#8: Concurrency• An extension of # 6 above.

• An implication to scale out.

• Not necessarily required for certain aspects (single process workers, etc)

#9: Disposability• Losing a process should be a normal event

• No loss of state for user if we lose a process

• Startup times should be low

• Platforms can adapt to errant processes and self heal if required.

#10: Dev / Prod Parity• Dev MUST == Production in config, but not performance

• Following the above helps do this

#11: Logs• Log everything

• Storage is cheap

• Searching is cheap

• Logs help fix problems after they happen

• Use tokens for specific flows

Measure/Monitor Everything

#12: Admin Processes• Use your app/framework for these... build in the tools as

needed.

• Don’t run updates directly against a database

• Don’t run them from a local terminal window

• ChatOps can help here

Importances: Moderate. Helps prevent mistakes

6 Laws of Systems that never stop• Isolation

• Concurrency

• Failure Detection

• Fault Identification

• Live Code Upgrade

• Stable Storage

http://www.infoq.com/presentations/Systems-that-Never-Stop-

More Resources• Pivotal Podcasts: Episode 23 (Operational transformation)

• You Build it, you run it - an interview with Werner Vogels

• This presentation