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

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

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

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

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

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

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

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

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

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

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

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

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