Twelve-Factor App
In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:
- Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
- Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
- Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
- Minimize divergence between development and production, enabling continuous deployment for maximum agility;
- And can scale up without significant changes to tooling, architecture, or development practices.
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
Cloud Native
Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.
Twelve-Factor App and Cloud Native
-
Code Base - One codebase tracked in revision control, many deploys
Cloud Native promotes one codebase per app and multi-deployment, for example, in production, staging, QA and development environments. -
Dependencies - Explicitly declare and isolate dependencies
Cloud Native's container model embraces the dependencies. -
Configurations - Store config in the environment
Cloud-native systems favor configuration information (such as URL and credentials) from an external configuration store. -
Backing Services - Treat backing services as attached resources
Cloud-native systems favor managed backing services from cloud vendors and treat a backing service as an attached resource, dynamically bound to service with configuration information (such as URL and credentials) stored in external configuration. -
Build, Release, Run - Strictly separate build and run stages
Modern CI/CD systems help fulfill this principle by providing separate build and delivery steps that help ensure consistent, and quality code is readily available to users. -
Processes - Execute the app as one or more stateless processes
Microservices promote the processes principle, while backing services promote the statelessness principle. -
Port Binding - Export services via port binding
In cloud-native environments, where services are often deployed in containers and orchestrated by platforms like Kubernetes, port binding is a fundamental mechanism for enabling communication between services and ensuring that they can be accessed by external clients. -
Concurrency - Scale out via the process model
Container orchestrators embraces concurrency. -
Disposability - Maximize robustness with fast startup and graceful shutdown
Container orchestrators embraces the disposability. -
Dev/Prod Parity - Keep development, staging, and production as similar as possible
Continuous deployment practices minimize the gaps between development and production. -
Logging - Treat logs as event streams'
Cloud-native observability includes monitoring, logging, tracing, metrics, alerting, etc. -
Admin Processes - Run admin/management tasks as one-off processes
Cloud-native principles advocate for running administrative or management tasks such as database migrations, backups, configuration changes, or periodic cleanup as a separate, standalone processes instead of embedding them in application code.