The Twelve Factors Applied to Microservices

 In current technology evaluation, 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

One codebase tracked in revision control, many deploys

In a microservices architecture, the correct approach is actually one codebase per service.

Explicitly declare and isolate dependencies

Regardless of what platform your application is running on, use the dependency manager included with your language or framework. In a containerized environment, do this in the Dockerfile.

Store config in the environment

Anything that varies between deployments can be considered configuration. As guidelines recommend, storing all configuration in the environment, rather than committing it to the repository. We recommend the following specific practices:

 - Use non‑version controlled .env files for local development. Docker supports the loading of these files at runtime.

 - Keep all .env files in a secure storage system, such as Vault, to keep the files available to the development teams, but not commited to Git.

 - Use an environment variable for anything that can change at runtime, and for any secrets that should not be committed to the shared repository.

 - Once you have deployed your application to a delivery platform, use the delivery platform’s mechanism for managing environment variables.

Treat backing services as attached resources

The implication for microservices is that anything external to a service is treated as an attached resource, including other services. This ensures that every service is completely portable and loosely coupled to the other resources in the system.

Strictly separate build and run stages

Recommend the use of a continuous integration/continuous delivery (CI/CD) tool to automate builds. Docker images make it easy to separate the build and run stages. Ideally, images are created from every commit and treated as deployment artifacts.

Execute the app as one or more stateless processes

For microservices, the important point in the Processes factor is that your application needs to be stateless. This makes it easy to scale a service horizontally by simply adding more instances of that service. Store any stateful data, or data that needs to be shared between instances, in a backing service.

Each service manages its own data

As a modification to make the Port binding factor more useful for microservices, we recommend that you allow access to the persistent data owned by a service only via the service’s API. This prevents implicit service contracts between microservices and ensures that microservices can’t become tightly coupled. Data isolation also allows the developer to choose, for each service, the type of data store that best suits its needs.

Scale out via the process model

In a microservices architecture, you can horizontally scale each service independently, to the extent supported by the underlying infrastructure. With containerized services, you further get the concurrency recommended in the Twelve‑Factor App, for free.

Maximize robustness with fast startup and graceful shutdown

Instances of a service need to be disposable so they can be started, stopped, and redeployed quickly, and with no loss of data. Services deployed in Docker containers satisfy this requirement automatically, as it’s an inherent feature of containers that they can be stopped and started instantly. Storing state or session data in queues or other backing services ensures that a request is handled seamlessly in the event of a container crash.

Keep development, staging, and production as similar as possible

Keep all of your environments – development, staging, production, and so on – as identical as possible, to reduce the risk that bugs show up only in some environments. To support this principle, we recommend, again, the use of containers – a very powerful tool here, as they enable you to run exactly the same execution environment all the way from local development through production. Keep in mind, however, that differences in the underlying data can still cause differences at runtime.

Treat logs as event streams

Instead of including code in a microservice for routing or storing logs, use one of the many good log‑management solutions on the market, several of which are listed in the Twelve‑Factor App. Further, deciding how you work with logs needs to be part of a larger APM and/or PaaS strategy.

Run admin/management tasks as one-off processes

In a production environment, run administrative and maintenance tasks separately from the app. Containers make this very easy, as you can spin up a container just to run a task and then shut it down.

Ref: https://www.nginx.com/blog/microservices-reference-architecture-nginx-twelve-factor-app/ 

Below are the Key Principles for doing microservices well,

Model Around Your Business Domain: Domain-driven design can help you find stable, reusable boundaries

Build a Culture of Automation: More moving parts means automation is key

Hide Implementation Details: One of the pitfalls that distributed systems can often fall into is tightly coupling their services together

Embrace Decentralization: To achieve autonomy, push power out of the center, organizationally and architecturally

Deploy Independently: Perhaps the most important characteristic microservices need

Focus on Consumers First: As the creator of an API, make your service easy to consume

Isolate Failure: Microservice architecture doesn’t automatically make your systems more stable

Make Them Highly Observable: With many moving parts, understanding what is happening in your system can be challenging