Speakers: Rags Srinivas, EMC; Matt Cowger, EMC
To learn more about Pivotal Cloud Foundry, visit http:///www.pivotal.io/platform-a-as-a-service/pivotal-cloud-foundry.
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
9.
10.
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.
12.
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)
15.
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.
17.
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
19.
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)
22.
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.
24.
25. #10: Dev / Prod Parity
• Dev MUST == Production in config, but not performance
• Following the above helps do this
26.
27.
28. #11: Logs
• Log everything
• Storage is cheap
• Searching is cheap
• Logs help fix problems after they happen
• Use tokens for specific flows
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