*Cross posted from my blog https://davidjeddy.com.
Disclaimer: Before we dive into my reasoning against Terraform let me state this: I personall...
For further actions, you may consider blocking this person and/or reporting abuse
The argument of an infrastructure-as-code solution preventing cloud vendor lock in is the same as Hibernate (or similar) preventing you from having DB lock in. Fallacy, as you have so many other issues and factors for cloud/db change that the provisioning/querying code is such a tip-of-the-iceberg....
I think it's not that you need (or don't need) Vault - it's just you need a solution to externalize secrets from the codebase in a secure manner.
Preventing vendor lock-in comes in two places:
To prevent that an out of the box approach is needed and first become with a good design. For example when you start with terraform you should logically separate the modules that are tied for each infrastructure provider, aws, gcloud or azure so that in case you want to change infrastructure you can import different modules in the live server deployment modules.
Ideally, the live server environments should not have internal knowledge of AWS or Gcloud but see them as black boxes.
Very much agreed. One of the best practices with IaC is the decoupling of the hardware running an application and the application services itself. If you have resources available I could use to help exemplify this decoupling I would love to share them.
On the point of frameworks, they are all opinionated. Using services with no alternatives; I agree. The business would have to make the decision between 'do we use the new hotness with no alternative' or 'do we hold off till we have choices to fall back to'. Either way, the conversation has to be started.
What do you think? Would you use a service that has not alternatives?
I’m running Kubernetes (ultimate cloud agnostic solution) on GCP + Terraform... still suffering from vendor lock-in. I agree, It’s a total pipe dream.
So very, very true.
This is true because they don't design to anticipate the change in infrastructure or the existing tooling is unknown to them or they don't know how to use it.