This message was deleted.

Hey @Bruno Kinoshita, can you clarify what you mean by "Terraform drivers as a backend"

If I understand correctly, to allow Infra self-service or "Environment as Code" some IDPs/tools has created drivers or webservices to connect with the infrastructure using Terraform. Humanitec Cloudify (Self Service Management UI), Port.io, Terraform no-code, Gaia, etc. That is, every plan/apply/destroy request comes from the IDPs and not from a tfvars stored in Git. That is, the IDP would be the new source of truth and it seems to me a new vendor lock-in and a dependence on the availability of the IDP to recover from disaster scenarios where infrastructure redeployment is required. Port.io showed me a very interesting alternative in which the platform simply works asynchronously with your current terraform stack (my own TF plan/apply pipelines, Stack instances, Atlantis, Infracost, etc). However, all automation to magically appear a "commit" with tfvars file in our repos, it's a job that my team has to do, but it allows us to keep git as the source of truth for our IaC. My point is, which approach makes the most sense to you? In terms of operation.

Hey @Bruno Kinoshita, I understand now, quick disclaimer: I'm the cofounder of Nullstone that also provides a similar strategy To answer the question "why not just use git for the source of truth": I would think of this trend with an analogy. Imagine a developer wanting authentication in their app. Instead of copying the code for authentication into their project, they include a library that solves authentication. Whoever builds the authentication library implements features and maintains the code. Now, think of Terraform (or other IaC) modules as libraries. A team has the responsibility of building reusable infrastructure components that are well-tested, meets compliance requirements, and provides an intuitive experience to developers. The developers can grab those modules off-the-shelf and use them knowing they are going to work and meet the company's security requirements. Some platforms, including Nullstone, provide a hybrid approach where you can describe your high-level architecture as an IaC file in your git repo, but the execution and stitching are performed by the platform.

Thanks for the answer @Bradley Sickles, it really makes a lot of sense. I wonder, what happens if I lose my entire Cloud platform due to someone's mistake, an attack, or a failure in the Cloud provider. Should the platform redeploy all the Cloud resources it created?

The platform should be capable of doing so, but the software team should have control over those decisions Recovering from disaster is usually nuanced to the company and team's ecosystem

Zohar, CEO of Port here :) Absolutely agree on the off-the-shelf library analogy! I’ll add here that in my opinion the underlying automation taking care of the IaC handling (library implementation) should be decoupled from the user experience & the IaC technology used (consuming library off the shelf). We built it in this way to allow you as a DevOps to make changes over time without impacting the DX. Port “do not care” if that’s TF or another IaC technology which reduces the tech debt you have if you couple between the two (disaster recovery, lock-in to specific tech stack, knowledge around specific tech, etc)

In our relatively small company (60+ engineers) IaC is located within the (micro)service repo and infra changes are part of CI/CD. Developers know exactly what underlying infra powers their service and how it’s configured. Guardrails are implemented via IAM and CODEOWNERS file. We provide the golden path using automated service creation via CI/CD.

Thanks for the answer guys. @Zohar Einy explained and demonstrated exactly what I meant through this article 👏 https://thenewstack.io/self-service-infrastructure-as-code-in-a-dev-portal-with-gitops/