0

Are there any advantages of maintaining both infrastructure (Infra-as-code) and application/service (helm chart deployment using helm_release provider of terraform ) under one state file?

I don't like the idea of maintaining both infra and application under one state, because for some reason it could be possible that our intention was just to change application however as there is one state and it could detect some other infra related change, and it will deploy them, which could have unintended consequences on the infrastructure.

however I would like to be open and see suggestion, if there are any advantages which maintaining one state file provides.

Improve this question

1 Answer 1

Reset to default
2

I tend to prefer infra code living separately from application deployment code. Multiple reasons for this:

  • You want your infra team to make infra changes. You want your app team to make application changes (including application configuration). Putting them separately lets you specify separate guard rails on them (for example, only the infra team is allowed to push changes to your infra repo).
  • You don't necessarily want to trigger a redeployment of the app if you make infra changes, and you rarely want to trigger a redeploy of your infrastructure if you trigger a new app build.
  • You don't want a bad build of your app preventing you from making any infrastructure changes until it's fixed, and vice-versa.

It actually makes sense to put your app deployment code (i.e. Helm chart) inside the app repo itself.

Then, you can actually package up application config changes along with the corresponding release of your application. You also empower developers to do it themselves, without running the risk of breaking production more than they already can.

It will also allow your CI/CD tool to deploy both at once.

And since there's a strict mapping of app IaC and app itself in each GitHub branch, this actually lets you very easily create feature branch environments (i.e. a developer creates a new branch, your CI/CD picks it up, and automatically deploys it to a kube environment).

Improve this answer
1
  • 1
    Having them applied separately and managed by separate states/ roles would also allow you to implement security and controls better, for example restricting who can create VPC, NAT Gateways, as you might not want your application developers to have that level of access to your accounts.
    – Alastair Montgomery
    Commented May 13, 2021 at 9:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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