FinOps Engineering — Defaults

FinOps Engineering — Utilising cost-optimised defaults in shared modules.

In the cloud almost all services have variable options for how they are configured where you can get more for more. More security, more reliability, more observability, more performance, higher price!

When creating shared modules (IaC, pipelines, ClickOps views, whatever) that are used by others to instantiate sets of infrastructure components to deliver some service then you need to be thoughtful regarding your defaults as they will have a big impact on aggregate outcomes!

No defaults

Have no default inputs.

This means that users will need to choose each variable feature that has a cost impact. This forces users to think about implications of choices. However it reduces DX by making the service harder to try / use initially and users also might input thoughtlessly just to move on quickly.

“Best practices”

Use best practice recommendations for all defaults.

Is the module being used only in production? Do you know enough about the production use cases to know what is right? If so then go ahead. Otherwise be more careful. My experience tells me that so often the defaults will be used outside of production and cause unnecessary waste.

Cost-optimised defaults

Use cost sensitive defaults.

This means that usage with defaults should just work in common cases. This will lead to the best aggregate cost outcomes. It will mean that users need to override certain settings to meet their needs sometimes. I recommend creating a guide to help them do this.

I also recommend hard-coding any defaults around security policy regardless of cost. This makes the most sense for internal modules where you understand the context of operation. Modules that you distribute more widely need to be more flexible.