12-Factor App
4 likes•2,018 views
The 12-Factor App methodology defines best practices for building software-as-a-service (SaaS) apps. It promotes apps that are highly scalable and portable by being self-contained and having their dependencies explicitly defined. The 12 factors cover aspects like codebase, dependencies, configuration, backing services, build and release processes, concurrency, disposability, development and production parity, and administrative tasks. Following the methodology helps apps maximize agility, reliability, and developability.
12-Factor App
- 1. 12-Factor App A Methodology for Building SaaS Apps MM Meetup, September 2015, Ankara /Abdullah Cetin CAVDAR @accavdar
- 2. Me :) Software Engineer Continuous Reader / Learner Runner / Rider Snooker Lover Headbanger m/ @udemy
- 3. 12factor.net
- 12. Is suitable for deployment on modern cloud platforms no need for servers and systems administration
- 15. The 12-Factors
- 18. tracked in a version control system: , , etc.git mercurial svn
- 25. pip
- 26. virtualenv
- 31. Resource Handles (db, memcache, backing services, ...) Credentials to external services (twitter, AWS, ...) Per-deploy values (canonical hostname, ...) PS: It does not include internal app config (config/routes.rb, bean config, ...)
- 33. Store config in Environment Variables Keep your config outside the app Env vars are easy to change between deploys No secret in version control
- 39. A backing service is any service the app consumes over the network Data Store (MySQL, MongoDB, AWS S3...) Messaging/Queueing Systems (RabbitMQ, Kafka, ...) Caching Systems (Redis, Memcached, ...) SMTP Services (Postfix, ...)
- 41. They are Attached Resources accessed via a URL or other locator/credentials stored in the config
- 43. They are loosely coupled with the deployed app They are easily swap out without any changes to the app’s code Microservices?
- 51. Use tools to easily rollback to previous release
- 52. Version your releases with unique release ids (ex: v101) Any change must create a new release
- 55. Never assume that anything cached in memory or on disk will be available on a future request or job Never use or rely on sticky sessions, use a data store that offers time- expiration, such as Memcached or Redis
- 58. Use dependency declaration to add a web server library Tornado for Python Thin for Ruby Jetty or Tomcat for Java
- 59. Use it not only for HTTP Any kind of service runs via a process binding to a port, i.e Redis Port-binding approach means that one app can become the backing service for another app
- 61. Processes are a first class citizen Developers can architect their app to handle diverse workloads by assigning each type of work to a process type HTTP requests may be handled by a web process Long-running background tasks handled by a worker process ...
- 63. Each process can handle its own multiplexing Threads in runtime VM (Java, ...) Async/Event model (Twisted, node.js, ...) Use system process managers (i.e Upstart) to Manage process Respond to crash process Handle user initiated restarts and shutdowns
- 64. Scale Out?
- 65. with share-nothing, horizontally partitionable nature of app processes Simple and Reliable Concurrency
- 67. Processes are disposable meaning they can be started or stopped at a moment’s notice fast elastic scaling rapid deployment of code and config changes robustness of production deploys
- 68. Minimize startup time more agility for the release process and scaling up aids robustness
- 69. Shut down gracefully when they receive a SIGTERM Cease to listen on the service port, allow any current requests to finish, and then exit (Web Process) Return the current job to the work queue (Worker Process) Try to make all jobs reentrant or Make the operation idempotent
- 73. Time Gap A developer may work on code that takes days, weeks, or even months to go into production
- 79. Make the tools gap small Keep development and production as similar as possible Resist to use different backing services between development and production Chef, Puppet, ... Docker, Vagrant, ...
- 83. Index and analyse (splunk, hive/hadoop, ...) your event streams to Finding specific events in the past Large-scale graphing of trends (such as requests per minute) Active alerting according to user-defined heuristics
- 85. One-off administrative or maintenance tasks for the app Running DB migrations Running a console (REPL shell) Running one time script
- 86. Run them in an identical environment as the regular app Ship with application code to avoid synchronization issues Favor languages which provide a REPL shell out of the box
- 88. Thank you :)
- 89. Questions?