The Twelve-Factor App methodology is a methodology for
building software-as-a-service applications. These best practices are designed
to enable applications to be built with portability and resilience when
deployed to the web.
1.
Code base
use version control, one repo per
application, git submodule, maven submodule
2.
Dependencies:
don't check jar in git, use
maven, artifactory, gcp artifact
3.
Config:
configuration should be strictly
separated from code. As per "config", what varies for the environment
to the environment must be moved to configurations and managed via environment
variables.
-
Database connections and credentials, system
integration endpoints
-
Credentials to external services such as Amazon
S3 or Twitter or any other external apps
-
Application-specific information like IP
Addresses, ports, and hostnames, etc.
Principle: can you make your app
opensource at anytime without compromising credentials
4.
Backing service:
Database, Message Brokers, any
other external systems that the app communicates is treated as Backing service.
Treat backing services as attached resources. like messaging service, postgre
sql with signle url that can be replaced without making your code change
5.
Build, release, run:
Build stage: transform the code
into an executable bundle/ build package.
Release stage: get the build
package from the build stage and combines with the configurations of the
deployment environment and make your application ready to run.
Run stage: It is like running
your app in the execution environment.
Strictly separate the process
with single command. You can use CI/CD tools to automate the builds and
deployment process. Docker images make it easy to separate the build, release,
and run stages more efficiently.
6.
Processes:
Execute the app as one or more
stateless processes
As per 12-factor principles, the
application should not store the data in in-memory and it must be saved to a
store and use from there. As far as the state concern, your application should
store the state in the database instead of in memory of the process.
Avoid using sticky sessions,
using sticky sessions are a violation of 12-factor app principles. If you would
store the session information, you can choose redis or memcached or any other
cache provider based on your requirements.
7.
Port binding :
Export services via port binding. The web app exports HTTP as a
service by binding to a port and listening to requests coming in on that port. Spring
boot is one example of this one. Spring boot by default comes with embedded
tomcat, jetty, or undertow.
8.
Concurrency:
By adopting the containerization,
applications can be scaled horizontally as per the demands.
9.
Disposability
Maximize robustness with fast Startup
and graceful shutdown. Docker containers can be started or stopped instantly.
Storing request, state, or session data in queues or other backing services
ensures that a request is handled seamlessly in the event of a container crash.
10. Dev/prod
parity
Keep development, staging, and
production as similar as possible. This reduces the risks of showing up bugs in
a specific environment.
11. Logs
Treat logs as event streams
observability is the first-class
citizen. Observability can be achieved through using APM tools (ELK, Newrelic,
and other tools) or log aggregations tools like Splunk, logs, etc.
12. Admin
processes
Run admin/management tasks as
one-off processes. Any needed admin tasks should be kept in source control and
packaged with the application.
Twelve-factor principles
advocates for keeping such administrative tasks as part of the application
codebase in the repository. By doing so, one-off scripts follow the same
process defined for your codebase.
Ensure one-off scripts are automated so that you don't need to worry about executing them manually before releasing the build. Twelve-factor principles also suggest using the built-in tool of the execution environment to run those scripts on production servers.
