12 Factor Methodology - A DevOps enabled approach to build and manage cloud native applications

To get maximum benefits out of cloud (from IaaS and PaaS), the applications should follow true cloud native design models with devops in mind. One of the best option in front of modern application developer is "12 factor application management methodology". This methodology was first presented by Adam Wiggins and commonly adopted by many organizations like Heroku, Cloud Foundry etc...

This methodology is programming language agnostic and based on below objectives.

1. Use declarative format to enable automation
2. Have a clean contract with underlying stack (e.g. PaaS layer or Operating system etc..) , to improve the portability between different target environments.
3. Minimize the divergence between development and production to enable continuous deployment.

The 12 factors need to be considered while developing modern applications are

1. Use single code base, to be tracked in revision control, and can be deployed multiple times. The codebase is the same across all deploys, although different versions may be active in each deploy.
2. All dependencies should be declared explicitly and isolate them from other applications, system tools and libraries. The application owner can create a dependency declaration manifest and can be applied uniformly to both development and production.
3. Store the production specific configuration in the production environment itself. Apps sometimes store config as constants in the code. Config varies substantially across deploys, code does not. Hence strict separation of configuration and code are required.
4. All backing services, like databases, should treat as attached supporting services. Backing services can be locally-managed services, or services that are provided and managed by third parties. The modern cloud native application should make no difference between local and third party services. To the app, both are attached resources, accessed through web services or other means.
5. There should be a devops pipeline and the pipeline should strictly consist of separate build, release, and run stages. At the same time the code base should be smoothly transformed through different stages of this pipeline with highest level of automation.
6. Deploy and execute the application as one or more stateless process and/or micro services. Any data that needs to persist must be stored in a stateful backing service, typically a database.
7. Export the self contained services to other services via TCP port binding. The application should not rely on runtime injection of a web container into the execution environment to create a web-facing service, instead it should export it as an HTTP/TCP service by binding to a specific port.
8. Scalability should be achieved by horizontally adding processes. This share nothing scale out model helps application to partition the data handling horizontally to different production systems. This improves the concurrency which is advocated by scaling individual processes.
9. Maximize the application robustness with disposability. The cloud native application should minimize the startup time and handle the SIGTERM (OS termination request) gracefully. This helps us to achieve fast elastic scaling, and rapid deployment of code or config changes with high resiliency.
10. Keep development, testing, pre-prod, and production environments are as similar as possible. There should minimum time gap (code dev to deployment time), personal knowledge gap (deployment engineer learning curve), and tool gap (same tools and versions across).
11. The cloud native application should generate logs as event streams and the system to handle it. When the application deploy in production, each service log stream will be captured by the execution environment, aggregate together with other log streams, and routed to centralized log management systems.
12. A separate management and admin process should be built in with the application and run as separate process.

Applying these factors into application development and operation are not easy. Any attempt will face many cultural, and technical challenges. Since there are no order for applying these best practices, the devops engineer can start with low hanging items and can show the improvements to the team and the stakeholders to get their support.