The Twelve Factored App
The cornerstone for a cloud native application or microservice is the Twelve Factor Application Methodology, drafted by developers at Heroku, a platform-as-a-service company so that applications were designed to take advantage of and run on a cloud native platform.
The sections below list these twelve factors.
1. One code base
Benefits:
A single consistent code base regardless of the execution environment.
Fully tracked in version control.
Allows for automated builds and tests.
2. Formalised Dependencies
All runtime and execution dependencies are formalised through a container, so that this container works on all platforms in a similar manner.
Packing the environment and the microservice into a container also allows a platform such as Kubernetes to create instances of the microservice easily. This provides elasticity by allow the platform the scale microservice instances up or down depending on traffic loads. It also provides resiliency by allowing the platform to spin up a new instance of the app if an existing instance becomes non-responsive.
Formalising dependencies in this manner is sometimes also referred to as Infrastructure as Code which can also be managed in the same version control.
3. Environment based Configuration
By having configuration information provided by the platform as environment variables, the microservice can change its deployment characteristics without resorting to hard-coded configuration information. This allows the platform to change configuration information as required through central platform configuration management so that incoming input streams can change or backend databases can change.
4. Replaceable Backing Services
The microservice should treat backend services, such as databases, SMTP servers and logging as replaceable attached resources. This allows these backing services to be changed centrally as necessary. For example, you can then change your HA DB to a single instance during maintenance, or upgrade your logging service to make use of analytics without having to change the microservice code.
5. Separate Build, Run, Release Stages
Having separate build, release and run stages verifies that all dependencies are properly formalised with each release having its own unique identifier. This allows release management to perform roll-backs when needed.
6. Stateless Processes
When the microservice is designed to be stateless, it allows multiple instances of the microservice to be run concurrently. This enables the execution platform to create new instances of the microservice when traffic increases or when a microservice instance is not responsive. It makes the microservice more elastic.
7. Port Binding
By exposing the microservice’s external interface through TCP ports, it allows:
other microservices and external applications to interface the service in a standard manner
the microservice to be self-contained
the routing layer to handle incoming requests
8. Concurrency
The microservice must be designed to work concurrently with other instances of the same microservice. This allows for microservice elasticity.
9. Disposability
Microservice must have quick startup and graceful shutdowns so that incoming requests can be quickly routed to a new instance of the microservice. Graceful quick shutdowns are necessary when demand has reduced, thereby conserving computing resources.
10. Dev-Prod Parity
By keeping the development and production environments as similar as possible, it ensures that processes to maintain and operate these environments are simplified and well understood by both the development and operations teams. It also ensures that all dependencies are formalised.
11. Logs as event streams
By making sure that microservices do not attempt to manage the storage of their own logs, it allows the handling of these logs centrally at the platform level.
12. Purpose built Admin Processes
By having purpose built administrative tools (such as DB migrations) for the environment, it allows the same privileges for dealing with the different environments. The source code for these tools should also be managed in version control. This allows different members of the microservices team to work on areas they may not be familiar with.