31–40 of 70 posts
As someone who doesn’t have any experience with GCP. But I do have experience with AWS, I would have thought this would already be a thing. I know AWS doesn’t have managed TF support - and as a former AWS ProServe employee i know that they thought about it but didn’t do it because they didn’t want to step on Hashicorp’s business. AWS does have its own hosted IAC service that was introduced before TF was a thing with…
As someone who doesn’t have any experience with GCP. But I do have experience with AWS, I would have thought this would already be a thing. I know AWS doesn’t have managed TF support - and as a former AWS ProServe employee i know that they thought about it but didn’t do it because they didn’t want to step on Hashicorp’s business. AWS does have its own hosted IAC service that was introduced before TF was a thing with…
I wouldn't be shocked to hear that licence fuckeries were the reasom why we don't have managed TF support of AWS.
Wonder if they have to pay licensing fees to hashicorp for using terraform this way. It’s essentially replacing terraform cloud for GCP resources.
Which is why it's all the more puzzling Google didn't spring for OpenTF here. They single-handedly could have proven it as the fork of choice but instead they're paying into HashiCorp's bad decision?
Earlier quoted context omitted.
In my experience, running a plan is much less likely to catch a bad value than the AWS provider. Subjectively, the AWS provider will at least validate that fields have valid values during the plan step. The Google provider doesn't seem to validate actual values until apply, and then you get a failure
I can’t help but feel… sad about this. I only recently picked up Terraform and am astounded that this is what goes as coding in the infrastructure world. I was coming from Ansible so there was only improvement to be had, but man did Terraform let me down so far. It (well, the provider) doesn’t validate fields until apply. That’s just so… sad. How is that acceptable? It’s like a car without a steering wheel, and peopl…
As someone who doesn’t have any experience with GCP. But I do have experience with AWS, I would have thought this would already be a thing. I know AWS doesn’t have managed TF support - and as a former AWS ProServe employee i know that they thought about it but didn’t do it because they didn’t want to step on Hashicorp’s business. AWS does have its own hosted IAC service that was introduced before TF was a thing with…
There is much more running on top of CloudFormation than meets the eye. CDK and SAM are both wrappers on top of CloudFormation. I wouldn't be shocked to hear that licence fuckeries were the reasom why we don't have managed TF support of AWS.
Earlier quoted context omitted.
I haven't used Cloudformation in three years, how's it doing these days?
I see a roughly even split of people using CFn, Terraform and (Python) CDK. AWS shot themselves in the foot by making the Python version of CDK second-tier after Typescript; IaC is still done by DevOps people far more often than application people, and DevOps people use Python. Another gripe is the number of services and new features which launch without CFn support, which also blocks CDK support; when Terraform supp…
I was really hoping this would come with rollback support for deployments. That, to me, would be the big advantage of having gcp manage the tfstate. It doesn’t look like that’s currently supported, but maybe that’s coming in the future.
Earlier quoted context omitted.
Just use CDK. By far it's the best way to manage AWS infra; AWS also uses it internally.
CDK uses CloudFormation under the hood.
It's not much different from high-level code compiling down to machine code. The benefit of writing high level code isn't that machine code is entirely gone. The benefit is instead that as a user you can mostly forget that machine code exists.