DOCKER BLACKSBURG MICHAEL IRWIN FEBRUARY 13, 2019 12-Factor Apps 12factor.net DOCKER BLACKSBURG

@mikesir87 Heroku Background ● Founded in 2009 as a platform-as-a-service ○ Currently supports easy deployment of apps written in Node, Ruby, Go, PHP, Java, Scala, Clojure, and Python ● “Heroku is a cloud platform that lets companies build, deliver, monitor and scale apps — we're the fastest way to go from idea to URL, bypassing all those infrastructure headaches.”

@mikesir87 Heroku Demo Video https://vimeo.com/134665146

@mikesir87 What’s it mean to be cloud native?

@mikesir87 What’s it mean to NOT be cloud native?

@mikesir87 “Cloud-native is about how applications are created and deployed, not where.” -- Pivotal Source: https://pivotal.io/cloud-native

@mikesir87 12-Factor Background ● Drafted by developers at Heroku ○ Based on experience of helping build and deploy hundreds of apps on the Heroku platform ● Initially presented in 2011 ○ Presented by Adam Wiggins, cofounder of Heroku

@mikesir87 Goals of 12-Factor Apps ● Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; ● Have a clean contract with the underlying operating system, offering maximum portability between execution environments; ● Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;

@mikesir87 Goals of 12-Factor Apps ● Minimize divergence between development and production, enabling continuous deployment for maximum agility; ● And can scale up without significant changes to tooling, architecture, or development practices.

@mikesir87 The 12 Factors 1. Codebase 2. Dependencies 3. Config 4. Backing Services 5. Build, release, run 6. Processes 7. Port Binding 8. Concurrency 9. Disposability 10. Dev/prod parity 11. Logs 12. Admin Processes

@mikesir87 1. Codebase ● Track using Git, SVN, Mercurial, something ● A one-to-one relationship between app and repo ○ Multiple repos isn’t a single app, but a distributed system. Each component is an app that can be 12-factor compliant ○ Multiple apps from same codebase should be refactored as libraries and included via dependency management ● Multiple deploys of the same app

@mikesir87 2. Dependencies ● Dependencies are explicitly declared in a manifest ○ Applies both for development and production ○ Java with pom.xml, Node with package.json, Ruby with Gemfile, etc. ● Applications should NOT rely on system-wide packages ○ Includes usage of system tools (even curl, bash, etc.) ○ Not all systems may have them available

@mikesir87 3. Config ● There should be strict separation of code and config ○ Config should NOT be bundled with the app ● Config = everything that can vary between deploys ○ Resource credentials (database, caches, API keys, etc.) ○ Hostname information ● Config should be provided with a combination of environment variables, injected files, configuration services

@mikesir87 4. Backing Services ● Treat backing services (db, caches, etc.) as attached resources ● The code for a twelve-factor app makes no distinction between local and third party services ● Goal is to be able to swap out a local resource with a managed resource with no change to the code itself ○ Example - Swapping local MySQL with RDS instance

@mikesir87 5. Build, release, run ● Strictly separate build and run stages ○ Build stage transforms code into an executable bundle ○ Run runs the bundle in a execution environment, combined with the config ● Each release should have a unique ID and be traceable back to the originating source

@mikesir87 6. Processes ● Apps should be executed as one or more stateless processes ● Each process should share nothing. Any data that needs to be persisted/shared should be done using a backing service ● Sticky sessions are a violation of twelve-factor

@mikesir87 7. Port Binding ● All apps/services should exposed via port binding ○ Should be fully self-contained and expose itself, rather than rely on a pre-existing HTTP server

@mikesir87 8. Concurrency ● Scale out by adding more processes ● Often talked about scaling horizontally rather than vertically ○ Horizontally refers to adding more machines, which start more processes ○ Vertically refers to adding more resources to existing processes to let them do more

@mikesir87 9. Disposability ● Apps should start and stop quickly and gracefully ○ Respond to SIGTERM events and start shutdown ● Includes idea of being “robust against sudden death” ○ Ensure message queues timeout and requeue messages if a handler dies due to hardware failure

@mikesir87 10. Dev/Prod Parity ● Keep all environments as consistent as possible ○ Supports easier ability for continuous deployment ● Use same backing services between dev and prod ○ Don’t use one queue/db in one tier and another type in another tier

@mikesir87 11. Logs ● Treat logs as event streams ○ Try to have one event per line (exception traces may span multiple lines) ○ No beginning or end as long as the app is running ● Stay away from routing or storage of the output stream within the app ○ Simply send data to stdout/stderr and let environment configuration determine where it should go

@mikesir87 12. Admin Processes ● Run admin/management tasks as one-off processes ○ Database migrations or other one-time scripts ● One-off scripts should utilize same dependency isolation techniques of apps themselves

@mikesir87 That’s it! (phew!)

@mikesir87 Where are we going next? ● We’ll spend a few more sessions talking about how we actually accomplish the various factors ● While containers make a lot of this easier, there are lots of tools to help

@mikesir87 Thanks! Questions?