Abstracted
Abstracted
Abstracted
What is Abstracted?
What is Abstracted?
Define interfaces to allow separation of secret and parameter value management from the interfaces that let those values be consumed.
Separate how code and configuration interact and isolate the specific values (ex: log level) from the configuration interface (how the log level value is fetched.)
Define interfaces to allow separation of secret and parameter value management from the interfaces that let those values be consumed.
Separate how code and configuration interact and isolate the specific values (ex: log level) from the configuration interface (how the log level value is fetched.)
Why Abstracted?
Why Abstracted?
Separation of concerns and responsibilities enables teams to deploy faster.
It creates an implicit communication channel; App devs make a change, and DevOps automatically see the change.
Separation of concerns and responsibilities enables teams to deploy faster.
It creates an implicit communication channel; App devs make a change, and DevOps automatically see the change.
Benefits
Benefits
Creates an implicit communication channel; app devs make a change, and ops automatically see the change.
Interfaces help make config obvious.
Examples
Examples
To spin up a new environment, the config interfaces are already defined, you only need to supply the values.
Components of your app can need different config formats, even though they may share data. Abstracting not just the required config but also the formats that config gets delivered in (JSON vs. YAML template) allows one to share data across components in a reliable fashion easily. An example is provisioning a database with Terraform. Terraform needs to know the database name, typically supplied in a tfvars file, but your app also needs that database name provided in a dotenv file. When config is abstracted, sharing a parameter delivered through a tfvars template and a dotenv file is possible.
Data generated by some components frequently need to be shared with others. For example, provisioning an AWS KMS key with Terraform and the generated identifier must be supplied to an application. By abstracting the configuration and associating its value with an external data source (e.g., Terraform state file), it is easy to run Terraform, generate the id, and have the app automatically pick up the value when its configured.
To spin up a new environment, the config interfaces are already defined, you only need to supply the values.
Components of your app can need different config formats, even though they may share data. Abstracting not just the required config but also the formats that config gets delivered in (JSON vs. YAML template) allows one to share data across components in a reliable fashion easily. An example is provisioning a database with Terraform. Terraform needs to know the database name, typically supplied in a tfvars file, but your app also needs that database name provided in a dotenv file. When config is abstracted, sharing a parameter delivered through a tfvars template and a dotenv file is possible.
Data generated by some components frequently need to be shared with others. For example, provisioning an AWS KMS key with Terraform and the generated identifier must be supplied to an application. By abstracting the configuration and associating its value with an external data source (e.g., Terraform state file), it is easy to run Terraform, generate the id, and have the app automatically pick up the value when its configured.