|
|
|
|
|
|
by TobbenTM
2965 days ago
|
|
|
I think the fear of changing infrastructure code is usually not rooted in bad practices, but rather immature tools and practices. Speaking from experience, it's really hard to get infrastructure as code deployments as bulletproof as application deployments, because you're so dependant on the toolchain, and its interaction with the provider (AWS, Azure, etc). And in some cases, it's impossible to actually do a clean infrastructure deployment without some manual steps, which leaves you wondering what new changes might need manual steps as well. 'Which problems have I not encountered yet?' |
|
|
I'm not sure I agree the dependency on the toolchain & provider, I am always able to read what API does (vendor side) and how it has been implemented (tool side) and make a educated decision. Caveat, I do not use bleeding edge features of any cloud provider and unless engineering requires - I do not use PaaS features of cloud providers - which i find have roughest edges for infra-as-code.
Secondly I think that part of that issue is maybe that the wrong toolchain is being used. eg: Trying to use HCL (hashicorp configuration language - used in Terraform) as if its turning complete. (and i've seen this before)
I've not run into an issue where manual steps are required to cleanly deploy infrastructure which I can not automate away. I can agree on dependency chains, where you may need to run your infrastructure deployment in sequence so that eg your network is up, before you provision instances.
All this being said, I mirror my production environment in staging. So 99% issues are found there.
I think we are mostly on the same page, I just took "scared" more literally than you.