際際滷

際際滷Share a Scribd company logo

12 factor apps

Alican Akku
Alican Akku

The document outlines the 12 factors for building software as a service (SaaS) applications. The factors are: 1) Codebase, 2) Dependencies, 3) Configuration, 4) Backing services, 5) Build, release, run stages, 6) Processes, 7) Port binding, 8) Concurrency, 9) Disposability, 10) Development/Production parity, 11) Logs, 12) Admin processes. The factors provide principles for building apps that are resilient, scalable and easy to develop and deploy.

1 of 15
Downloaded 60 times
THE 12 FACTORS LIGHTNING TALKS ALICAN AKKUS@IYZICO 1
THE 12 FACTORS 1 2 3 4 5 6 8 10 7 11 9 Codebase One codebase tracked in revision control, many deploys. Dependencies Explicitly declare and isolate dependencies. Con鍖guration Store con鍖g in the environment. Backing Services Treat backing services as attached resources. Build, release, run Strictly separate build and run stages. Processes Execute the app as one or more stateless processes. 12 Port binding Export services via port binding. Disposability Maximize robustness with fast startup and graceful shutdown. Dev/Prod Parity Keep development, staging, and production as similar as possible Logs Treat logs as event streams. Concurrency Scale out via the process model. Admin processes Run admin/management tasks as one-off processes. 2
THE 12 FACTORS 1 Codebase One codebase tracked in revision control, many deploys. This means you must not have various codebase for various versions. Branches and tags is okay, different repos are not. 3
THE 12 FACTORS 2 Dependencies A twelve-factor app never relies on implicit existence of system-wide packages.It declares all dependencies, completely and exactly, via adependency declarationmanifest. 4
THE 12 FACTORS 3 Con鍖guration Store con鍖g in the environment. The most important rule here is never commit your environment-speci鍖c con鍖guration (most importantly: password) in the source code repo. Otherwise your production system may be vulnerable. 5
THE 12 FACTORS 4 Backing Services Treat backing services as attached resources. A backing service is one that requires a network connection to run. This is a very popular paradigm found in modern application development, especially prevalent with the rise in popularity of microservice architecture. The 12-Factor App methodology advises developers to treat these services agnostically, meaning changes or modi鍖cations should occur without having to make any code changes. 6
THE 12 FACTORS 5 Build, release, run Strictly separate build and run stages. The twelve-factor app uses strict separation between the build, release, and run stages.For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage. 7
THE 12 FACTORS 6 Processes Execute the app as one or more stateless processes. Twelve- factor processes are stateless andshare-nothing.Any data that needs to persist must be stored in a statefulbacking service, typically a database. 8
THE 12 FACTORS 7 Port binding Export services via port binding. The twelve-factor app is completely self-containedand does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web appexports HTTP as a service by binding to a port, and listening to requests coming in on that port. 9
THE 12 FACTORS 8 Concurrency Scale out via the process model. In the twelve-factor app, processes are a 鍖rst class citizen.Processes in the twelve- factor app take strong cues fromthe unix process model for running service daemons. Using this model, the developer can architect their app to handle diverse workloads by assigning each type of work to aprocess type. 10
THE 12 FACTORS 9 Disposability Maximize robustness with fast startup and graceful shutdown. The twelve-factor appsprocessesaredisposable, meaning they can be started or stopped at a moments notice.This facilitates fast elastic scaling, rapid deployment ofcodeorcon鍖gchanges, and robustness of production deploys. 11
THE 12 FACTORS 10 Dev/Prod Parity Keep development, staging, and production as similar as possible. The twelve-factor app is designed forcontinuous deploymentby keeping the gap between development and production small. 12
THE 12 FACTORS 11 Logs Treat logs as event streams. A twelve-factor app never concerns itself with routing or storage of its output stream.It should not attempt to write to or manage log鍖les. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the apps behavior. 13
THE 12 FACTORS 12 Admin processes Run admin/management tasks as one-off processes. Theprocess formationis the array of processes that are used to do the apps regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app. 14
THANKS 15 https://12factor.net https://dzone.com/articles/the-12-factor-app-a-java-developers-perspective https://www.sitepoint.com/12-factor-apps-methodology-implement-apps-appfog/

More Related Content

12 factor apps

  • 1. THE 12 FACTORS LIGHTNING TALKS ALICAN AKKUS@IYZICO 1
  • 2. THE 12 FACTORS 1 2 3 4 5 6 8 10 7 11 9 Codebase One codebase tracked in revision control, many deploys. Dependencies Explicitly declare and isolate dependencies. Con鍖guration Store con鍖g in the environment. Backing Services Treat backing services as attached resources. Build, release, run Strictly separate build and run stages. Processes Execute the app as one or more stateless processes. 12 Port binding Export services via port binding. Disposability Maximize robustness with fast startup and graceful shutdown. Dev/Prod Parity Keep development, staging, and production as similar as possible Logs Treat logs as event streams. Concurrency Scale out via the process model. Admin processes Run admin/management tasks as one-off processes. 2
  • 3. THE 12 FACTORS 1 Codebase One codebase tracked in revision control, many deploys. This means you must not have various codebase for various versions. Branches and tags is okay, different repos are not. 3
  • 4. THE 12 FACTORS 2 Dependencies A twelve-factor app never relies on implicit existence of system-wide packages.It declares all dependencies, completely and exactly, via adependency declarationmanifest. 4
  • 5. THE 12 FACTORS 3 Con鍖guration Store con鍖g in the environment. The most important rule here is never commit your environment-speci鍖c con鍖guration (most importantly: password) in the source code repo. Otherwise your production system may be vulnerable. 5
  • 6. THE 12 FACTORS 4 Backing Services Treat backing services as attached resources. A backing service is one that requires a network connection to run. This is a very popular paradigm found in modern application development, especially prevalent with the rise in popularity of microservice architecture. The 12-Factor App methodology advises developers to treat these services agnostically, meaning changes or modi鍖cations should occur without having to make any code changes. 6
  • 7. THE 12 FACTORS 5 Build, release, run Strictly separate build and run stages. The twelve-factor app uses strict separation between the build, release, and run stages.For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage. 7
  • 8. THE 12 FACTORS 6 Processes Execute the app as one or more stateless processes. Twelve- factor processes are stateless andshare-nothing.Any data that needs to persist must be stored in a statefulbacking service, typically a database. 8
  • 9. THE 12 FACTORS 7 Port binding Export services via port binding. The twelve-factor app is completely self-containedand does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web appexports HTTP as a service by binding to a port, and listening to requests coming in on that port. 9
  • 10. THE 12 FACTORS 8 Concurrency Scale out via the process model. In the twelve-factor app, processes are a 鍖rst class citizen.Processes in the twelve- factor app take strong cues fromthe unix process model for running service daemons. Using this model, the developer can architect their app to handle diverse workloads by assigning each type of work to aprocess type. 10
  • 11. THE 12 FACTORS 9 Disposability Maximize robustness with fast startup and graceful shutdown. The twelve-factor appsprocessesaredisposable, meaning they can be started or stopped at a moments notice.This facilitates fast elastic scaling, rapid deployment ofcodeorcon鍖gchanges, and robustness of production deploys. 11
  • 12. THE 12 FACTORS 10 Dev/Prod Parity Keep development, staging, and production as similar as possible. The twelve-factor app is designed forcontinuous deploymentby keeping the gap between development and production small. 12
  • 13. THE 12 FACTORS 11 Logs Treat logs as event streams. A twelve-factor app never concerns itself with routing or storage of its output stream.It should not attempt to write to or manage log鍖les. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the apps behavior. 13
  • 14. THE 12 FACTORS 12 Admin processes Run admin/management tasks as one-off processes. Theprocess formationis the array of processes that are used to do the apps regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app. 14