0

Imagine you have decided to abstract from exact service location.

Normally, you have a cody world with the service name=DNS.

Say, you have prototyped something with S3 compatible API like exoscale/pithos.

But then you think okay this was actually a mockup and now you go for real S3 in production.

Would you rewrite the stack, trick around with ${ENV_VARIABLES} or is there some more elegant way to proceed?

1

As per https://12factor.net/config, configuration like this should be stored as environment variables.

The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

A service that you connect to is suitable to be defined as configuration, so the use of env vars is appropriate here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.