"The twelve-factor app principle is a 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. Lagom is a well-known framework for developing microservices. In this knolx session, we would be discussing the twelve-factor app principle with respect to lagom development. "

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

24. References
https://12factor.net
https://www.lagomframework.com/
https://blog.knoldus.com/the-twelve-factor-app-principle-with-lagom-framework/

25. Thank You !