Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Twelve-Factor App

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/

Awesome Incremented

August 15, 2015
Tweet

More Decks by Awesome Incremented

Other Decks in Technology

Transcript

  1. Background • Guidelines by Adam Wiggins (Heroku) • Partly self-serving

    (of course) • Good practices to examine – even if not doing fancies like cloud & web apps
  2. 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
  3. 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.
  4. 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
  5. 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.
  6. 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
  7. 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!
  8. 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.
  9. 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
  10. 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.
  11. 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
  12. 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.
  13. 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
  14. 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.
  15. 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.
  16. 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
  17. Tooling • Most factors language-independent – dependencies, config, disposability, ...

    • Special tooling – Port brokering  Heroku, Docker – Dev/prod parity  Vagrant, Docker – Log capturing  ELK-Stack
  18. 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)