This post is
to share my understanding about Twelve Factor Apps by Adam Wiggins.
Twelve
Factor Apps is a methodology for building software as a service apps that,
•
Use
declarative formats, to ease the setup for new developers
•
Have
clean contract to offer maximum portability between environments
•
Adopt
modern cloud platforms
•
Enable
CI & CD
•
Can
scale up significantly
Motivation
of Twelve Factor Apps is to raise awareness about the systematic problems, to
provide shared vocabulary & to offer broad conceptual solutions to those
problems.
1. Code Base
§ Use Single Repository to deploy one
app in multiple environments using labels/changesets
- Every app should have dedicated
repo, multiple apps sharing a single repo is a violation of Twelve Factor
apps
2. Dependencies
§ Make App dependencies as system wide
common packages eg. Npm, yarn, maven modules
§ It will help developers to setup any
given project faster
- Apps should not rely on implicit
existence of packages
3. Configuration
§ Export all configuration parameters as
environment variables
§ Configurations that are not going to
change between environments can be maintained implicitly in the app (not in the
code as hardcoded)
§ Group the parameters based on
environments, to configure the same way ahead before different environment deployments
(this may not scale as expected, when new env is required manual intervention
is required)
4. Backing Services
§ Backing services are the
services/resources used by the app over network (eg. Databases, Queues)
§ Every distinct backing service is a
resource, each service/resource should be loosely coupled by using enterprise
integration patterns (event-driven).
§ Any change to the resource should not
impact the app’s code
§ Eg. If the database server doesn’t
respond as expected, then a new instance of the database should be easily
attached to the app
5. Build, Release & Run
§ A code base is transformed into
deployable component through the below stages,
•
Build
Stage – prepares executables
•
Release
Stage – applies configurations to the built executables
•
Run
Stage – launches the app in target environment
§ Every release should have a unique ID,
a release cannot be mutated, which allows roll backing the release to previous
concrete release
§ Have strict separation between the
stages
6. Processes
§ A app can be executed as a single or
multiple processes
§ App should be stateless and
share-nothing. The state of the app should be persisted in the backing
services.
§ Design the app to be stateless, it
will help to scale the same
7. Port Binding
§ An app should be self-contained, it
exposes HTTP as a service by binding to a port and listens to serve the
incoming requests
§ In environment deployments, routing
table will take care of routing the dns name to specific port bounded web
process
8. Concurrency
§ In twelve factor apps, processes are
first class citizen
§ Designing an app stateless &
share-nothing mode means that adding more concurrency is simple & reliable
operation
§ Long running task can be moved to a
worker model which can scale independently
§ App should never daemonize instead it
should respond to manage streams, crashes, user-initiated restarts &
shutdowns
9. Disposability
§ App process should strive to minimize
start up time (this helps to scale faster)
§ Also it should gracefully shutdown (to
stop receiving request & process the received request then exit)
§ The app should be architected
considering to handle crashes, unhandled, non-graceful terminations due to
hardware failures.
§ Recommended approach will be to have a
robust queue to backup the request before processing
10. Dev/Prod Parity
§ Keep development, staging & prod
environments as similar as possible
§ App should be designed for continuous
deployment by keeping the gap b/w environments as small as possible
|
Factors
|
Traditional
app
|
Twelve-factor
app
|
|
Time between
deploys
|
Weeks
|
Hours
|
|
Code authors vs code deployers
|
Different
people
|
Same people
|
|
Dev vs
production environments - Tools
|
Divergent
|
As similar
as possible
|
§ Backing services cannot be different
between dev & prod environments
11. Logs
§ Treat Application Logs as Event
Streams
§ Log Streams can be used to analyse the
behaviour, collect metrics, store for audit purposes
§ Log Streams can be made to flow
through another business process mode to find specific events, identifying
trends, to introspect over time period
12. Admin Processes
§ Run admin/management tasks as one-off
processes
§ Eg. Gateways which introspects every
request for routing, rename context paths
§ Admin code must be shipped with
application code to avoid synchronization issues using dependency isolation
technique
Reference:
https://www.dynatrace.com/news/blog/twelve-factor-app-now-fifteen-factor
