Speakers: Rags Srini­vas, EMC; Matt Cowger, EMC To learn more about Pivotal Cloud Foundry, visit http:///www.pivotal.io/platform-a-as-a-service/pivotal-cloud-foundry.

2. 12 Factor Apps for
Operations
rags srinivas (@ragss)
matt cowger (@mcowger)

4. #1: Codebase
• Everything in revision control
• Including environment configuration

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

6. Well the environment
didn't change!
— every. ops. person. ever.

7. Revision Control ->
git blame
(svn blame if you must)

8. #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

11. #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.

13. • 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

14. #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)

16. #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.

18. #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

20. #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.

21. #8: Concurrency
• An extension of # 6 above.
• An implication to scale out.
• Not necessarily required for certain aspects (single process
workers, etc)

23. #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.

25. #10: Dev / Prod Parity
• Dev MUST == Production in config, but not performance
• Following the above helps do this

28. #11: Logs
• Log everything
• Storage is cheap
• Searching is cheap
• Logs help fix problems after they happen
• Use tokens for specific flows

31. Measure/Monitor
Everything

33. #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

34. 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-

35. More Resources
• Pivotal Podcasts: Episode 23 (Operational transformation)
• You Build it, you run it - an interview with Werner Vogels
• This presentation