1. The 12 Factors to build Cloud Native Applications
> A methodology for building Software as a Service applications
> Originated fromt engineers working at Heroku
> A focus on stateless applications suitable for modern cloud platforms
Pivotal Cloud Foundry 12 steps to Cloud Native

2. Pivotal Cloud Foundry 12 steps to Cloud Native
The 12 Factors
> Codebase
> Dependencies
> Config
> Backing services
> Build, release, run
> Processes
> Port binding
> Concurrency
> Disposability
> Dev/prod parity
> Logs
> Admin processes
Pivotal Cloud Foundry 12 steps to Cloud Native

3. Pivotal Cloud Foundry 12 steps to Cloud Native
Codebase
What
> Each codebase must be stored in version control
> One-to-one relationship between application and codebase
> One-to-many relationship between codebase and deploys
Why
> To support collaboration between developers and teams
> To enable proper versioning
How
> Git, Subversion, Mercurial, etc.
Pivotal Cloud Foundry 12 steps to Cloud Native

4. Pivotal Cloud Foundry 12 steps to Cloud Native
Dependencies
What
> Explicitly declare and isolate application dependencies
> Use a declaration manifest that’s stored with the codebase
> Use a dependency isolation tool during application execution
Why
> Provides consistency between dev/prod environments
> Simplifies setup for developers new to the application
> Supports portability between cloud platforms
How
> Nuget
Pivotal Cloud Foundry 12 steps to Cloud Native

5. Pivotal Cloud Foundry 12 steps to Cloud Native
Config
What
> Ensure strict separation between code and configuration
> Store configuration in environment variables
Why
> Modify application behaviour without making code changes
> Simplifies deployment to multiple environments
> Reduce risk of leaking credentials and passwords
How
> Extract all application config to environment variables
> cf set-env
Pivotal Cloud Foundry 12 steps to Cloud Native

6. Pivotal Cloud Foundry 12 steps to Cloud Native
Backing Services
What
> Treat backing services (E.g. MySQL) as attached resources
> Make no distinction between local and third party services
> Attach resources via URLs stored in the app’s config
Why
> Provides loose coupling between service and deployment
> No code changes required to update backing services
> Allows operators to swap services out as they see fit
How
> cf marketplace, cf create/bind-service
Pivotal Cloud Foundry 12 steps to Cloud Native

7. Pivotal Cloud Foundry 12 steps to Cloud Native
Build, Release, Run
What
> Strictly separate the build, release and run stages
Why
> To prevent changes to code and/or configuration at runtime …
> … which in turn lowers the number of unexpected failures
How
> cf push
Pivotal Cloud Foundry 12 steps to Cloud Native

8. Pivotal Cloud Foundry 12 steps to Cloud Native
Processes
What
> Execute the app as one or more stateless processes
> Ensure all stateful data is stored in a backing service
Why
> Reduce deployment complexity
> Reduce operational complexity
> Allow for much simpler scaling
How
> Store any stateful data in backing services
> Do not use sticky sessions or the local filesystem!
Pivotal Cloud Foundry 12 steps to Cloud Native

9. Pivotal Cloud Foundry 12 steps to Cloud Native
Concurrency
What
> Scale out via the process model
> Treat processes as first class citizens
> Do not daemonize processes or attempt to write PID files
Why
> Allows for easy, horizontal scaling
How
> Split app into separate, runnable processes
> Scale independently
Pivotal Cloud Foundry 12 steps to Cloud Native

10. Pivotal Cloud Foundry 12 steps to Cloud Native
Disposability
What
> Maximise robustness via fast startup and graceful shutdown
> Treat app instances as cattle, not pets
> Be resilient to unexpected and sudden shutdowns (SIGKILL)
Why
> To facilite fast, elastic scaling
> To allow for rapid deployment of new code/config changes
> Provide robustness in production deployments
How
> Minimise work on startup, don’t depend on shutdown hooks
Pivotal Cloud Foundry 12 steps to Cloud Native

11. Pivotal Cloud Foundry 12 steps to Cloud Native
Dev/prod Parity
What
> Keep development, staging and production deploys as similar as possible
Why
> Lower risk of unexpected errors / downtime in production
> To support continues deployment
How
> Ensure the same backing services are used for all deployments
> Ensure a solid Continues Integration pipeline
> Deploy to production as often as possible
Pivotal Cloud Foundry 12 steps to Cloud Native

12. Pivotal Cloud Foundry 12 steps to Cloud Native
Logs
What
> Treat logs as event streams
> Log to stdout and stderr only
> Do not think about storage of logs at all
Why
> To make logging a platform concern, not a developer concern
> Improved flexibility for introspecting behaviour over time
How
> log to stdout/stderr only, cf logs
Pivotal Cloud Foundry 12 steps to Cloud Native

13. Pivotal Cloud Foundry 12 steps to Cloud Native
Admin Processes
What
> Run admin/management tasks as one-off processes
> Store code for admin tasks with the app’s codebase
> E.g. One-off debug tasks, REPL access to production
Why
> Safely support debugging/admin of production applications
How
> cf run-task
Pivotal Cloud Foundry 12 steps to Cloud Native