12-Factor App Overview

Developing applications is tough. Especially in the ever-changing environments. We have local development. QA validation. Pre-prod/staging. Production. But, how do we ensure our applications work the same everywhere? While containers help out, they aren't the only thing to keep in mind. The folks at Heroku, in 2011, published "The Twelve-Factor App", which has become the standard for building cloud-native applications.

Over the next several events, we're going to talk about the various points and what they might look like in a containerized world, including many additional tools and services in the ecosystem.

Transcript

1. DOCKER BLACKSBURG MICHAEL IRWIN FEBRUARY 13, 2019 12-Factor Apps 12factor.net DOCKER BLACKSBURG
2. @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.”
3. @mikesir87 Heroku Demo Video https://vimeo.com/134665146
4. @mikesir87 What’s it mean to be cloud native?
5. @mikesir87 What’s it mean to NOT be cloud native?
6. @mikesir87 “Cloud-native is about how applications are created and deployed, not where.” -- Pivotal Source: https://pivotal.io/cloud-native
7. @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
8. @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;
9. @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.
10. @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
11. @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
12. @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
13. @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
14. @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
15. @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
16. @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
17. @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
18. @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
19. @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
20. @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
21. @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
22. @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
23. @mikesir87 That’s it! (phew!)
24. @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
25. @mikesir87 Thanks! Questions?