Building Microservices | 12 Factor App - Externally Managed Config | InterviewDOT
Channel: Interview DOT
Date: 2020-03-31

Click here - https://www.youtube.com/channel/UCd0U_xlQxdZynq09knDszXA?sub_confirmation=1 to get notifications.

Tamil Building Microservices | 12 Factor App - Externally Managed Config | InterviewDOT

The twelve-factor app methodology is a methodology for building software-as-a-service applications. These best practices are designed to enable applications with portability and resilience to be deployed to the web.

The 12 Factor App Manifesto gives some recommendations on how best to develop web apps for the cloud. A good SaaS application must be easily scalable, quickly deployable and easily portable. However, this is not so easy to guarantee. However, the standards proposed by the manifest are not applicable to all applications.

A 12-factor app relies on the explicit existence declaration of all dependencies, completely and exactly, via a dependency declaration manifest. And you must also use a dependency isolation tool along with dependency declaration.

Store the configuration in environment variables
The configuration is an app everything probably between Deploys will change (staging, production, development environments, etc.). This includes:

Resource handles for databases, memcached and other supporting services
Credentials for external services such as Amazon S3 or Twitter
Values ​​directly dependent on the deploy, such as the canonical host name for the deploy
Sometimes apps save the configuration as constants in the code. This is a violation of the twelve factors. They demand strict separation of the configuration from the code . The configuration changes significantly from deploy to deploy, in contrast to code.

A litmus test of whether an app has completely outsourced the configuration is if the codebase could be published as open source at any time without disclosing credentials.

It should be noted that this definition of "configuration" does not include the internal application configuration , as config/routes.rbin Rails or how code modules are wired to Spring . This type of configuration does not change from deploy to deploy and is therefore part of the code.

As a configuration, you could also use files that are not checked into version management as config/database.ymlin Rails. This is a significant improvement over using constants that are checked into version management, but has weaknesses. It is relatively easy to accidentally check a configuration file into the repo. In addition, there are tendencies to scatter configuration files in different locations and in different formats. This makes it difficult to manage the configuration from one point. Furthermore, these formats are often language or platform specific.

The twelve-factor app saves the configuration in environment variables (briefly also env vars or env ). Changing environment variables from deploy to deploy is easy; in contrast to configuration files, it is unlikely that they will be accidentally checked into the code repository and in contrast to special configuration files or other configuration mechanisms such as the Java properties, they are language and operating system independent.

Another aspect of configuration management is grouping. Sometimes apps collect the configuration in named groups (often called “environments”), named after certain deploys such as the environments development, testand productionin rails. This method does not scale properly: the more deploys an app has, the more environment names are needed, such as stagingor qa. If the project continues to grow, developers could joes-stagingadd their own special environments such as . In the end, the configuration explodes combinatorially and the administration of the deploys becomes error-prone.

In a twelve-factor app, environment variables are granular set screws and completely orthogonal to each other. They are never summarized as “environments”, but can be managed independently for each deploy. This model scales up smoothly when the app naturally expands to more deploys over its lifetime.

A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials.