Twelve Factor App With Lagom
0 likes133 views
The document presents an overview of the Twelve Factor App methodology, which provides best practices for building scalable and resilient software as a service applications. It details each of the twelve factors, such as codebase, dependencies, config, and processes, emphasizing their importance for modern app development, particularly using the Lagom framework. The document concludes with references for further reading on both the Twelve Factor methodology and Lagom framework.
Twelve Factor App With Lagom
- 1. Presented By: Girish Chandra Bharti (Sr. Software Consultant @ Knoldus) Twelve Factor App with lagom
- 2. Agenda 01 Introduction of twelve factor app 02 Explanation of individual principle 03 Question and answer session 04 References 60 6
- 3. Twelve factor app principle ●Methodology for building software as a service application and these best practices are designed to enable applications to be built with portability and resilience when deployed to the web. ●It was drafted by developers at Heroku and was first presented by Adam Wiggins circa 2011.
- 4. Twelve factor app principle ● I. Codebase ● II. Dependencies ● III. Config ● IV. Backing services ● V. Build, release, run ● VI. Processes ● VII. Port binding ● VIII. Concurrency ● IX. Disposability ● X. Dev/prod parity ● XI. Logs ● XII. Admin processes The 12 factors
- 5. I. Codebase ● Revision control in plase. ● If there are multiple codebases, it’s not an app – it’s a distributed system. ● Each component in a distributed system is an app, and each can individually comply with twelve-factor. ● Multiple apps sharing the same code is a violation of twelve-factor. ● The solution here is to factor shared code into libraries which can be included through the dependency manager. One codebase tracked in revision control, many deploys
- 6. I. Codebase ● Lagom follows this principle partially as it allows single codebase for application but also multiple services sharing the same codebase. ● That can be avoided by shared libraries. Lagom with single codebase
- 7. II. Dependencies ● It declares all dependencies, completely and exactly, via a dependency declaration manifest ● Twelve-factor apps also do not rely on the implicit existence of any system tools (eg curl). Explicitly declare and isolate dependencies
- 8. II. Dependencies ● Lagom follows this principle by allowing explicit dependency declaration using build.sbt (scala). Lagom dependency handling
- 9. III. Config ● Configurables: - Resource handles to the database, Memcached, and other backing services - Credentials to external services such as Amazon S3 or Twitter - Per-deploy values such as the canonical hostname for the deploy ● Storing config as constants in the code is a violation of twelve-factor Store config in the environment
- 10. IV. Backing services ● A backing service is any service the app consumes over the network as part of its normal operation (mysql, couchDB, kafka) ● The code for a twelve-factor app makes no distinction between local and third party services. ● To the app, both are attached resources, accessed via a URL or other locator/credentials stored in the config. ● A deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party (such as Amazon RDS) without any changes to the app’s code. Treat backing services as attached resources
- 11. V. Build, release, run ● The twelve-factor app uses strict separation between the build, release, and run stages. Strictly separate build and run stages
- 12. V. Build, release, run ● Lagom app deployment: 1. Build (Bundle) 2. Config (RP Tool) 3 Deployment (Marathon) Lagom supports for build, release, and run stages.
- 13. VI. Processes ● Twelve-factor processes are stateless and share-nothing. ● Any data that needs to persist must be stored in a stateful backing service, typically a database. ● The twelve-factor app never assumes that anything cached in memory or on disk will be available on a future request or job ● Sticky sessions (user session) are a violation of twelve-factor and should never be used or relied upon. Execute the app as one or more stateless processes
- 14. VI. Processes ● Lagom supports event sourcing to handle stateless processes By writing event into third party database like Cassandra (by default) ● Distributed pub-sub ● CRDTS (Conflict-free replicated data type for future) Process model of lagom
- 15. VII. Port binding ● Port-binding approach means that one app can become the backing service for another app, by providing the URL to the backing app as a resource handle in the config for the consuming app. ● The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service ● The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port. Export services via port binding
- 16. ● Lagom allows to create microservices and let other services consume them using port bindings. ● To access them from outside we can make the rest rest calls VII. Port binding Port binding in lagom
- 17. ● Using this model, the developer can architect their app to Handle diverse workloads by assigning each type of work to a process type. ● For example, HTTP requests can be handled by a web process, and long-running background tasks handled by a worker process VIII. Concurrency Scale out via the process model
- 18. ● Supports CQRS for handling reads and writes ● Supports different dispatcher dispatchers and execution contexts VIII. Concurrency Scale out via the process model
- 19. ● The twelve-factor app processes are disposable, meaning they can be started or stopped at a moment’s notice. ● Processes should strive to minimize startup time. ● Processes shutdown gracefully when they receive a shutdown signal from the process manager IX. Disposability Maximize robustness with fast startup and graceful shutdown
- 20. ● Supports fast startup while deploying the application however build takes time to finish (On local might take time to start the application) ● Support graceful shutdown for rest apis and background processes ● Supports graceful shutdown for persistence entities ● User defined actors can be designed to support graceful shutdown IX. Disposability Fast startup and graceful shutdown in lagom
- 21. ● The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small. ● Recommendations: - Make the time gap small - Make the personnel gap small - Make the tools gap small X. Dev/prod parity Keep development, staging, and production as similar as possible
- 22. ● Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services Advantages: ● Finding specific events in the past. ● Large-scale graphing of trends ● Active alerting XI. Logs Treat logs as event streams
- 23. ● Additional administrative or maintenance tasks for the app: - Running database migrations - Running a console - Running one-time scripts ● One-off admin processes should run in an identical environment as the regular long-running processes of the app XII. Admin processes Run admin/management tasks as one-off processes
- 25. Thank You !
Editor's Notes
- #2: Note: First “Right Click” on the Gradient background, go to “Order” option and “Send it to Back”, then insert your picture into “Image Placeholder”, “Right Click” on the picture and again go to “Order” option and “Send it to Back” to get the “Gradient” effect. <number>
- #6: Revision control in plase. If there are multiple codebases, it’s not an app – it’s a distributedsystem. Each component in a distributed system is an app, and each canindividually comply with twelve-factor. Multiple apps sharing the same code is a violation of twelve-factor. The solution here is to factor shared code into libraries which can be included through the dependency manager.
- #7: Lagom follows this principle partially as it allowssingle codebase for application but also multipleservices sharing the same codebase. That can be avoided by shared libraries.
- #8: It declares all dependencies, completely and exactly, via a dependency declaration manifest Twelve-factor apps also do not rely on theimplicit existence of any system tools (eg curl).
- #9: Lagom follows this principle by allowing explicitdependency declaration using build.sbt (scala).
- #10: Configurables: - Resource handles to the database, Memcached, and other backing services - Credentials to external services such as Amazon S3 or Twitter - Per-deploy values such as the canonical hostname for the deploy Storing config as constants in the code is a violation of twelve-factor
- #11: A backing service is any service the app consumes over the networkas part of its normal operation (mysql, couchDB, kafka) The code for a twelve-factor app makes no distinction betweenlocal and third party services. To the app, both are attached resources, accessed via a URL or otherlocator/credentials stored in the config. A deploy of the twelve-factor app should be able to swap out a localMySQL database with one managed by a third party (such as AmazonRDS) without any changes to the app’s code.
- #12: The twelve-factor app uses strict separationbetween the build, release, and run stages.
- #13: Lagom app deployment:1. Build (Bundle)2. Config (RP Tool)3 Deployment (Marathon)
- #14: Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a statefulbacking service, typically a database. The twelve-factor app never assumes that anything cachedin memory or on disk will be available on a future request or job Sticky sessions (user session) are a violation of twelve-factorand should never be used or relied upon.
- #15: Lagom supports event sourcing to handle stateless processesBy writing event into third party database like Cassandra (by default) Distributed pub-sub CRDTS (Conflict-free replicated data type for future)
- #16: Port-binding approach means that one app can become the backing service for another app, by providing the URL to the backing app as a resource handle in the config for the consuming app. The twelve-factor app is completely self-contained and doesnot rely on runtime injection of a webserver into the executionenvironment to create a web-facing service The web app exports HTTP as a service by binding to a port,and listening to requests coming in on that port.
- #17: Lagom allows to create microservices and let other servicesconsume them using port bindings. To access them from outside we can make the rest rest calls
- #18: In the twelve-factor app, processes are a first class citizen. Using this model, the developer can architect their app to Handle diverse workloads by assigning each type of work to a process type. For example, HTTP requests can be handled by a web process, and long-running background tasks handled by a worker process
- #19: Supports CQRS for handling reads and writes Supports different dispatcher configurations for various actors Supports various execution contexts
- #20: The twelve-factor app processes are disposable, meaningthey can be started or stopped at a moment’s notice. Processes should strive to minimize startup time. Processes shutdown gracefully when they receive a shutdownsignal from the process manager For a web process, graceful shutdown is achieved by ceasing tolisten on the service port (thereby refusing any new requests),allowing any current requests to finish, and then exiting For a worker process, graceful shutdown is achieved by returningthe current job to the work queue
- #21: Supports fast startup while deploying the application howeverbuild takes time to finish (On local might take time to start theapplication) Support graceful shutdown for rest apis and background processes Supports graceful shutdown for persistence entities User defined actors can be designed to support graceful shutdown
- #22: The twelve-factor app is designed for continuous deployment bykeeping the gap between development and production small. Recommendations: Make the time gap small: a developer may write code and haveit deployed hours or even just minutes later. Make the personnel gap small: developers who wrote code areclosely involved in deploying it and watching its behavior inproduction. Make the tools gap small: keep development and production assimilar as possible.
- #23: Logs are the stream of aggregated, time-ordered events collectedfrom the output streams of all running processes and backing services Advantages: Finding specific events in the past. Large-scale graphing of trends (such as requests per minute). Active alerting according to user-defined heuristics (such as an alertwhen the quantity of errors per minute exceeds a certain threshold).
- #24: Additional administrative or maintenance tasks for the app: - Running database migrations - Running a console - Running one-time scripts One-off admin processes should run in an identical environment as the regular long-running processes of the app
- #26: <number>