[ADR] Terraform as one specification for whole infrastructure or per application/microservice

[piotrczyz]

Context

• Is there a possibility to unify the way how we create infrastructure in the cloud?
• How we can handle common architecture in the future?
• How to track changes in architecture
• Manually created architecture is fast to create but hard to maintain and often only one person is responsible for architecture in a specific app.

Decision

• [Oskar] Terraform is the answer - it creates unify way for infrastructure, and it's based on the IaC approach. Even if there are different providers per cloud way how we apply changes on infra and syntax are similar, it's also really easy to have ready templates for bcc usage like (creating cloud storage, load balancer, external IP, and cert for the new app) -> all in one file COLLECTION REPO

• [Oskar] Shared infrastructure is challenging, here is a link to a short video with HashiCorp (terraform company) CTO VIDEO LINKIn 3:30 he starts to describe our challenge and shows the solution. We should separate common components (like monitoring, logs, API gateway, network ) from App-Specific infrastructure (like app bucket, API hosting server, database). And I think this is the best way to have freedom in teams and common infrastructure under control. In the future, we can use "Registry" as a set of predefined ways to create environments per application - but probably it's too complex for now.

• [Jakub] Terraform is a great tool that allows us to generate infrastructure quicker (in the long run) and more reliably.

• [Jakub] Shared architecture should be managed by a dedicated team and separated from app specific architecture.

• [Jakub] I don't think having a CI/CD for deploying architecture is very helpful as IMO we would still have to maintain the ability to deploy locally to all environments for the following reasons:

  1. Faster development cycle
  2. Finer control (can deploy/destroy/recreate selected resources)

• [Jakub] Additionally local deployment gives better security:

  1. Uses personal credentials - no need to create the terraform-superuser
  2. Some platforms only support personal credentials (github), which shouldn't be shared (as they would be in a CI/CD pipeline).

Consequences

• [Oskar] We need a team that will be responsible for common architecture (like API gateway) or we have to set up automatic CI/CD which helps to securely apply changes, like after adding a line to main.tf with a new API gateway endpoint config there is the flow that checks if the config is correct and asks for approving someone from infra team.

• [Jakub] Someone needs to take ownership of the shared architecture and maintain it.

Alternatives

• [Oskar] Alternatives for terraform is to use specific cloud tools like gcloud or azure cli which we are doing already in github actions, but terraform can handle infrastructure on a higher level (create, update, delete) and provide unified language.

• [Jakub] Create architecture manually, as we always did

• [Jakub] Use custom scripts

[github-actions[bot]]

Remember that ADRs are publicly available hence do not include any confidential information in the issue description! To read more about ADR please refer to documentation.

[rvanoord]

Would an alternative to a dedicated "infrastructure" team be, that one or two people from each product team are part of a cross product-team "infrastructure team"? Changes could be approved by the tech leads in each team? @oskarpbcc

[oskarpbcc]

Sure, an infrastructure team can exist in an ideal world or bigger companies. For our needs, we can discuss what infrastructure is common and create it. Team leads should be aware of what looks like infrastructure and we can add the "approve step" after "terraform plan" and before "terraform apply" commands :)