1.CodeBase: One codebase tracked in revision control, many deploys
Multiple codebases for multiple versions must be avoided.
Please do note that having branches would be fine. I.e. For all the deployment environments there should be only one repo but not multiple.
Microservices: In Microservices, every service should have its own codebase. Having an independent codebase helps you to easy CI/CD process for your applications.
2.Dependencies(Explicitly declare and isolate the dependencies)
Managing the dependencies externally using dependency management tools instead of adding them to your codebase.
Microservices: All the application packages will be managed through package managers like sbt, maven.
3.Config(Store configurations in an environment)
This principle states that configurations of an application need to be stored independently from the code itself, as environment variables, or in a configuration file.
Examples of configuration data includes:
Database connections and credentials, system integration endpoints
Credentials to external services such as Amazon S3 or any other external apps
Application-specific information like IP Addresses, ports, and hostnames, etc.
Should not be hardcoded any configuration values as constants in the codebase.
These configuration data are different for each of the deployment environments where the application is going to run. By separating such configuration data, we’re making it easy to run the application in different environments.
As shown in the fig. below that when running in different landscapes, the same codebase is run, but different sets of configuration data are applied in different environments.
4.Backing Services(treat backing resources as attached resources)
This principle suggests that services such as databases, messaging systems, Simple Mail Transfer Protocol (SMTP) services, and so on, should be architected as external resources. The application consumes these backing services over the network.
In the figure below, you can see an example of an SAP Cloud Application Programming Model application accessing three different resources.Each of these backing services is referred to as a resource.
12-factor app can automatically swap the application from one provider to another without making any further modifications to the code base. Let us say, you would like to change the database server from MySQL to Aurora. To do so, you should not make any code changes to your application. Only configuration change should be able to take care of it.
5.Build, release, and Run(Strictly separate build and run stages)
The application must have a strict separation between the build, release, and run stages.
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.
Microservices:
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)
This principle states that applications should have the provision to be served by multiple stateless, independent processes, as shown in this figure.
Consider that a user’s request is served by process 1. Subsequent requests should be able to be served by process 2 or any other processes as well. There will be no session data maintained in any of the processes, and each process independently serves the request without communicating with other processes. Any data that needs to persist must use a backing service such as a database.
Following this principle makes it easy to scale the infrastructure up and down, thus making it ideal for cloud deployments.
7.Port binding(Export services via port binding)
The twelve-factor app is a self-contained standalone app that doesn’t require a web server 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.
Microservices: Spring boot is one example of this one. Spring boot by default comes with embedded tomcat, jetty, or undertow.
8.Concurrency(Scale out via the process model)
This talks about scaling the application. Twelve-factor app principles suggest to consider running your application as multiple processes/instances instead of running in one large system. You can still opt-in for threads to improve the concurrent handling of the requests.
Microservices: By adopting the containerization, applications can be scaled horizontally as per the demands.
9.Disposability(maximize the robustness with fast startup and graceful shutdown)
A twelve-factor app should maximize robustness with fast startup and graceful shutdown.
The processes should minimize the time to startup and ideally take a few seconds to start and receive the incoming requests; it helps while scaling up the processes.
At the same time, the processes should shut down gracefully and cease to listen on the service port without allowing any incoming requests; in such cases, if there is a queuing system, the requests can be queued and processed once the processes are up.
10.Dev/prod parity(Keep development, staging, and production as similar as possible)
The twelve-factor methodology suggests keeping the gap between development and production environment as minimal as possible. This reduces the risks of showing up bugs in a specific environment.
Microservices: This is an inherent feature of the Microservices that is run using the containerization techniques.
11.Logs(Treat logs as event streams)
Logs become paramount in troubleshooting the production issues or understanding the user behavior. Logs provide visibility into the behavior of a running application.
A twelve-factor app never concerns itself with storing the log information in the app, as it can die and, as a result, lose the information. Instead, the app should treat log entries as event streams and use a separate service to save them.
Microservices: In Microservices, observability is the first-class citizen. Observability can be achieved through using APM tools (ELK and other tools) or log aggregations tools like Splunk, logs, etc.
12.Admin processes(Run admin/management tasks as one-off processes)
The developer often needs to perform administrative or maintenance activities for apps that need data migration, running processes, or one-time scripts. These should also be identical across different landscapes (DEV, QA, and PROD). These processes should also be shipped along with the application code to avoid synchronization issues.
Microservices: Containerization also helps here to run the one-off processes as a task and shutdown automatically one done with the implementation.
Happy Learning!!
Thanks For Reading 🙂