The Twelve-Factor App

Slides supporting an introductory talk on the 12 factor app guidelines from Heroku. Most content courtesy to http://www.clearlytech.com/2014/01/04/12-factor-apps-plain-english/

Transcript

1. The Twelve-Factor App scalable, portable, easy-to-deploy web apps in the cloud Dev.Talk August 2015 Marcel Körtgen
2. Background • Guidelines by Adam Wiggins (Heroku) • Partly self-serving (of course) • Good practices to examine – even if not doing fancies like cloud & web apps
3. Goals • Automate all the things! – new members up to speed quickly • Clear contract to environment – maximum portability • Deployable to cloud – implies scalability • Dev/Prod -parity – implicitly testing continuous deployment
4. I. Codebase • One codebase tracked in revision control, many deploys – codebase run by developers on their local machines – deployed to any number of other environments • Importance: Non-negotiable. – Everyone does this, and developers will laugh at you if you aren’t.
5. II. Dependencies • Explicitly declare all dependencies – libs: no-brainer (Maven, NuGet, Gems, …) – other, e.g. database, command line tools, … • Chef, Puppet, Docker to the rescue! • Isolate dependencies – No shared folder!  update fear • Importance: High – Without, constant slow time-suck of confusion and frustration multiplied by size and number of apps
6. III. Config • Store config in environment – Anything varying between environments • database, credentials, log level – Strictly separated from code! – Environment variables, no grouping! • Importance: Medium – Lots of companies get away without this, but you’re sloppy if you do – Automate to get zero friction!  again Chef & co.
7. IV. Backing Services • Any service your app uses – database, cache, email service, queue, etc. • Treat as attached resources – simple endpoint (URL) + opt. authentication • Allows great flexibility – replace local instance with one on AWS ElastiCache • Importance: High – Given current service bindings, there’s little reason not to do this
8. V. Build, release, run • Strictly separate build and run stages – build: code  bundle of scripts, assets and binaries – release: bundle + config(server)  server – run: start release on server(s) • Importance: Conceptual – Usually tooling defines build, release, run • Enforcing strict separation varies, though – Just follow suggested mechanisms • If there are none, you are in trouble!
9. VI. Processes • Execute the app as one or more stateless processes – app runs on many servers  fault tolerance, traffic – state persisted in database, shared storage • Importance: High – stateless  more robust, easier to manage, generally incurs fewer bugs, and scales better.
10. VII. Port binding • Export services via port binding – Extends factor IV (Backing Services) – app uses services, app is a service • Importance: Medium – Most runtime frameworks give this for free. – If not, don’t sweat it. It’s a clean way to work, but it’s generally not hard to change later
11. VIII. Concurrency • Scale out via the process model – Not Threads! Processes!  host independent – Don‘t manage yourself! • No daemons/services • instead use OS process manager (upstart, systemd, etc.) • Importance: Low – Don’t worry until you get deep into scaling – Trust your chief architect or CTO to raise the red flag if this is going to become an issue for you.
12. IX. Disposability • Maximize robustness with fast startup and graceful shutdown – Allows for very fast scaling and load shifting – Startup: Have everything warmed up, serve requests almost instantly – Shutdown: Ctrl+C, no cleanup tasks (again: stateless) • Importance: Medium – Depends on release rate (x/day) and demand to scale traffic up and down – Be sure to understand the implications, though
13. X. Dev/prod parity • Keep development, staging, and production as similar as possible – Rapid dev/prod cycles (x hours)  cost effective – Minimize risk to break something when entering production • Importance: Medium – Devs take shortcuts if their local environment is working “well enough” – Talk them out of it and take a hard-line stance instead, it’ll pay off long-term.
14. XI. Logs • Treat logs as event streams – Log to stdout – Capture and push into real-time consolidated system for long-term archival and data-mining – ELK-Stack is great for this! • Importance: Medium – Don’t rely on logs alone – If you need logs so bad, you maybe in trouble
15. XII. Admin processes • Run admin/management tasks as one-off processes – e.g. cleanup bad data, running analytics, turning on and off features for A/B testing • Importance: High – Console access to production is critical – Every major language/framework provides it – No excuses for sloppiness here.
16. Summary • Very cloud centric, some even seem esoteric • But the heart of a happily running system is an architecture that is – robust, reliable, and surprises us as little as possible. • 12 factors adopted by most major software platforms and frameworks, – cut corners against their grain is a bad idea. • Discuss and see if there are some quick wins to improve the quality of your application design.
17. 12x App vs. Microservices • „Microservice“  no clear definition • Is a 12x App a Microservice?  Yes • Some people argue a microservice – does not have a UI – may have state
18. Tooling • Most factors language-independent – dependencies, config, disposability, ... • Special tooling – Port brokering  Heroku, Docker – Dev/prod parity  Vagrant, Docker – Log capturing  ELK-Stack
19. Some references • 12-Factor Apps in Plain English (clearlytech Blog) • Twelve-Factor App: Web-Applikationen auf die neue Art (innoQ Podcast) • 12 Factor Microservices on Docker (Packt Publishing) • 5 Lessons We’ve Learned Using AWS (NetFlix Tech Blog, 2010) • Application Server sind tot! (E.Wolff, Jaxenter, 2014)
20. Thank You Time for Questions!