There are certain times we know that, if we understand certain things, our work is 22.29% 
done. This is one such day for you. I tell you why, before that, to point out something, there was a time, around the height of popularity in Microservice, when a lot of people were telling that Microservices are small, independent, communicate through well-defined interfaces (like REST APIs), and provide business value. We know that DevOps teams are gradually transforming their infrastructure into a self-serve platform to avoid relying on tools from any single third party. Yes, yes, I am getting to it in just about a minute. It is wise and beneficial to look at the concepts underlying such a cloud-native design. And hence, 12 factor app came into picture.
12 factor apps concept give an insight on how to build applications that give software as a service.
Advantages
- Use declarative formats; minimize time, cost
- Offer maximum portability between execution environments
- Suitable for deployment on cloud platforms
- Enabling continuous deployment
- Can scale up easily
1. Codebase
One codebase tracked in revision control, many deploys
Code of the app is always tracked using version control systems like Git
Do
There is always a one-to-one correlation between the app and it’s codebase. If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is a 12 factor app
There may be many deploys (running instances) of the app
Don’t
Multiple apps sharing the same code is a violation of twelve-factor
2. Dependencies
Explicitly declare and isolate dependencies
Do
Declare all dependencies, completely and exactly, via a dependency declaration manifest
Use dependency isolation tool to ensure no implicit dependency leak in
Don’t
Never relies on implicit existence of system-wide packages
3. Config
Store config in the environment
Do
Keep everything that is likely to vary between deploys in config
Resource handles to the database, Mem cached, and other backing services
Credentials to external services such as Amazon S3 or Twitter
Per-deploy values such as the canonical host name for the deploy
Environment variables needn’t be checked into GitHub
Don’t
Storing config as constants in code
4. Backing Service
Treat backing services as attached resources
Backing service is any service the app consumes over the network
For example, DB, messaging/queuing service, cache, SMTP etc
Do
Make no distinction between local and third party services
Both should be accessed via a URL or other locator/credentials stored in the config
Resources can be attached and detached to deploys at will
Don’t
Make changes to app’s code to change resource
5. Build, release, run
Strictly separate build and run stages
Codebase is converted into a deploy-able file through three stages:
Build stage: Transform code to an executable bundle. Fetches dependencies, compiles binaries and assets.
Release stage: Combines the build with the deploy's current config.
Run stage: run the app in execution environment.
6. Process
Execute the app as one or more stateless processes
Do
Execute app as a stateless process that share nothing between each other
Complex apps may have many stateless processes
Data that has to be persisted should be stored in stateful backing service
Don’t
Never assumes that anything cached in memory or on disk will be available on a future request or job
Sticky sessions are a violation of twelve-factor and should never be used or relied upon
7. Port binding
Export services via port binding
A 12-factor app must be self-contained and bind to a port specified as an environment variable
Do
Similar to all the backing services you are consuming, your application must also interfaces using a simple URL
Create a separate URL to your API that your website can use which doesn’t go through the same security (firewall and authentication), so it’s a bit faster for you than for untrusted clients
Don’t
It can’t rely on the injection of a web container such as tomcat or unicorn; instead it must embed a server such as jetty or thin
8. Concurrency
Scale out via the process model
Do
Because a 12-factor exclusively uses stateless processes, it can scale out by adding processes
Ensure that a single instance runs in its own process. This independence will help your app scale out gracefully as real-world usage demands
Don’t
Not desirable to scale out the clock processes, though, as they often generate events that you want to be scheduled singletons within your infrastructure
9. Disposability
Maximize robustness with fast startup and graceful shutdown
Do
Use components that are ready and waiting to serve jobs once your app is ready
Technologies to consider are databases and caches like RabbitMQ, Redis, Memcached, and CenturyLink’s own Orchestrate. These services are optimized for speed and performance, and help accelerate startup times
Don’t
You should never do any mandatory “cleanup” tasks when the app shuts down that might cause problems if they failed to run in a crash scenario
10. Dev/prod parity
Keep development, staging, and production as similar as possible
The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small
Do
Adopt continuous integration and continuous deployment models
Public cloud services make the infrastructure side easy, at least between QA/test, staging and production. This is one of Docker’s primary benefits (CF)
Don’t
Using different backing services (databases, caches, queues, etc) in development as production increases the number of bugs that arise in inconsistencies between technologies or integration
11. Logs
Treat logs as event streams
A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles
Do
View logs in local consoles (developers), and in production, view the automatically captured stream of events which is pushed into real-time consolidated system for long-term archival
Stream the logs to two places: view these logs in real-time on your dev box and store them in tools, like ElasticSearch, LogStash and Kafka. SaaS products like Splunk are also popular for this purpose
Don’t
Don’t rely on these logs as the primary focus
12. Admin processes
Run admin/management tasks as one-off processes
Do
Admin/management tasks mentioned in the final factor should be done in production
Perform these activities from a machine in the production environment that’s running the latest production code
access to production console
Don’t
Updates should not be run directly against a database or from a local terminal window, because we get an incomplete and inaccurate picture of the actual production issues
Conclusion
As long as the application is stable, robust, reliable, and any adjective you give, the architecture of the application will be strong and these 12 factors are adopted by many major platforms and frameworks to improve the quality of the product. No matter where you stand, what language you use, use the right of 12 factors for the job, because, what you make with your code is how you express yourself.