4 ms·

> use whatever the cloud you are using has built it (cloudformation, deployment manager, etc). Not applicable if you're deploying infra across cloud (we do tha

by oxplot 5y ago

> use whatever the cloud you are using has built it (cloudformation, deployment manager, etc). Not applicable if you're deploying infra across cloud (we do that across a dozen cloud providers!). Without terraform, it'll bring us tears. > Or about when it just loses tracks of resources. Never had this in years of using terraform. These should be qualified with how often they occur. > Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. Checkout the code from before the change and apply again. I've done this numerous times and it's been as good as a natively supported rollback. > HCL? A disaster. Why is it a disaster? I find it predictable, ergonomic and easy to write. I also really like the JSON compatibility. But this one is I guess mostly taste. > it's a terrible tool I've found Cloudformation to be an abomination as far as user experience goes! Every time I used it, I lost a bit of my soul.

rantwasp 5y ago
nah. i’ve heard the cross-cloud argument multiple times and it does not hold any water. i wish we lives in a world where we could do cloud agnostic stuff but the reality is that you have your aws terraform files, your gcp terraform files and so on. Cloudformation? Like the tool that bring you from state A to state B or if it cannot rolls back to state A? Yeah. It’s an abomination for a tool to leave infra in a consistent state. Who would want that? Re: checkout the code and apply again. What if I told you that terraform can mess up so hard that it won’t work? What if I told you that sometimes you will not be able to rollback OR even destroy your infra? Here is an exercise for you. Create some infra with terraform and do a destroy and tell me if it managed to cleanup everything? I’m gonna bet you that for anything less than trivial you are gonna have a bad time. The solution? Tag shit and use a python script to cleanup. I’m not even kiddding.
- psadauskas 5y ago
  We use it all the time. Not to deploy to multiple "cloud providers", but to update dnsimple domains with the cloudfront endpoint, set hirefire rules for heroku dynos, and create kapacitor alerts. It's great that they can all reference vales from other services, and it's broken up by coherent services, rather than where it's being hosted.
- technocratia 5y ago
  >nah. i’ve heard the cross-cloud argument multiple times and it does not hold any water. This, I use terraform every day at my work and I really like it compared to cloudformation but I never understood the cross-cloud advertisement. If I deploy, say, RDS cluster and Kinesis streams with terraform, how on earth is it cross platform?
  - oxplot 5y ago
    See my other comment. It's not about a single resource working across providers, but the ability to reference resources across providers and linking them together. Think Cloudflare pointing to AWS endpoints.
- oxplot 5y ago
  > nah. i’ve heard the cross-cloud argument multiple times and it does not hold any water. You misunderstood. I'm talking a single terraform project provisioning resources across different providers. We have AWS resources referencing stuff in Cloudflare and the other way, and Cloudflare referencing stuff in a k8s cluster running on-site. Add some some GCP LBs referencing a whole bunch of endpoints across 6 providers. They're all under a single TF project and a single tf apply makes changes across all of them.
chippiewill 5y ago
> Checkout the code from before the change and apply again. I've done this numerous times and it's been as good as a natively supported rollback. Almost as good as native but not quite. Often times applys fail because you've introduced new providers with new resources. If you checkout the previous code and apply again then TF will explode because there's resources in the statefile that are now missing providers. So you have to manually patch in the provider from the new version on top of the old version just to remove the resources.

by oxplot 5y ago

rantwasp 5y ago

nah. i’ve heard the cross-cloud argument multiple times and it does not hold any water. i wish we lives in a world where we could do cloud agnostic stuff but the reality is that you have your aws terraform files, your gcp terraform files and so on. Cloudformation? Like the tool that bring you from state A to state B or if it cannot rolls back to state A? Yeah. It’s an abomination for a tool to leave infra in a consistent state. Who would want that? Re: checkout the code and apply again. What if I told you that terraform can mess up so hard that it won’t work? What if I told you that sometimes you will not be able to rollback OR even destroy your infra? Here is an exercise for you. Create some infra with terraform and do a destroy and tell me if it managed to cleanup everything? I’m gonna bet you that for anything less than trivial you are gonna have a bad time. The solution? Tag shit and use a python script to cleanup. I’m not even kiddding.

psadauskas 5y ago
We use it all the time. Not to deploy to multiple "cloud providers", but to update dnsimple domains with the cloudfront endpoint, set hirefire rules for heroku dynos, and create kapacitor alerts. It's great that they can all reference vales from other services, and it's broken up by coherent services, rather than where it's being hosted.
technocratia 5y ago
>nah. i’ve heard the cross-cloud argument multiple times and it does not hold any water. This, I use terraform every day at my work and I really like it compared to cloudformation but I never understood the cross-cloud advertisement. If I deploy, say, RDS cluster and Kinesis streams with terraform, how on earth is it cross platform?
- oxplot 5y ago
  See my other comment. It's not about a single resource working across providers, but the ability to reference resources across providers and linking them together. Think Cloudflare pointing to AWS endpoints.
oxplot 5y ago
> nah. i’ve heard the cross-cloud argument multiple times and it does not hold any water. You misunderstood. I'm talking a single terraform project provisioning resources across different providers. We have AWS resources referencing stuff in Cloudflare and the other way, and Cloudflare referencing stuff in a k8s cluster running on-site. Add some some GCP LBs referencing a whole bunch of endpoints across 6 providers. They're all under a single TF project and a single tf apply makes changes across all of them.

chippiewill 5y ago

> Checkout the code from before the change and apply again. I've done this numerous times and it's been as good as a natively supported rollback. Almost as good as native but not quite. Often times applys fail because you've introduced new providers with new resources. If you checkout the previous code and apply again then TF will explode because there's resources in the statefile that are now missing providers. So you have to manually patch in the provider from the new version on top of the old version just to remove the resources.