What is 12 factor in Cloud Native
What is Cloud Native
Cloud Native was first proposed by Matt Stine of Pivotal in 2013. Pivotal has open-sourced the Java development framework SpringBoot and Spring Cloud. Later, Google established CNCF (CloudNative Computing Foundation) in 2015, which has attracted more and more attention to Cloud Native.
Essentially, Cloud Native is a design pattern that requires Cloud Native applications to have availability and scalability, the ability to automatically deploy and manage, and can run anywhere. It can improve the efficiency of research and development, testing, and release through continuous integration and continuous delivery tools.
Twelve Factors of Cloud Native
“The Twelve-Factor App” was proposed by Adam Wiggins, the founder of Heroku in 2012. The characteristics mentioned in the twelve factors are not specific to cloud providers, platforms, or languages. These factors represent a set of guidelines or best practices for portable elastic applications (especially “software as a service” applications) that are thriving in the cloud environment.
- Codebase: One codebase, many deploys
- Dependencies: Explicitly declare dependencies
- Configuration: Store configuration in the environment
- Backing services: Treat backing services as attached resources
- Build, release, run: Strictly separate build and run stages
- Processes: Execute the app as one or more stateless processes
- Port binding: Export services via port binding
- Concurrency: Scale out via the process model
- Disposability: Maximize robustness with fast startup and graceful shutdown
- Dev/prod parity: Keep development, staging, and production as similar as possible
- Logs: Treat logs as event streams
- Admin processes: Run admin/management tasks as one-off processes
Advanced Twelve Factors
After the release of the twelve factors, Kevin Hoffman, who works at Pivotal, published the book “Beyond the Twelve-Factor App”, which not only elaborated on the original twelve factors in more detail but also added three new factors.
- API First: Prioritize API design like a contract, which should be changed as little as possible once it takes effect. If it is modified after being put into use, its impact may be difficult to control and may affect many external systems.
- Telemetry: For applications deployed in the cloud environment, their system environment is closed and isolated. When problems occur, you should not log in to problematic physical servers to observe and collect the application’s status.
- Authentication and Authorization: It is dangerous to completely leave security issues to the cloud platform, so it is recommended to use more complete security mechanisms such as OAuth2 authentication and RBAC authorization.
Reference
https://12factor.net
- Future Architecture: From Service to Cloud Native
- Cloud Native Architecture Advanced Practice
- Scalable Architecture (2nd Edition): High Availability and Risk Management in Cloud Environments
https://zhuanlan.zhihu.com/p/243404169
https://architecturenotes.co/12-factor-app-revisited/