I do not like terraform and I believe it's a terrible tool.
Here is the error you get when it fails:
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.
If that error does not give you pause, I don't know what will.
It's basically YOLO-ing it and in case it does not work you're on your own.
It's also leaving you in whatever state and now you need to figure out what it managed to do, what didn't work and figure out how to 1) make it work 2) make terraform understand that it worked. Usually this happens at the worst time when you are deploying to production.
Do we want to talk about when plan "works" but it craps out on "apply"?
Or about when it just loses tracks of resources.
HCL? A disaster. Why would you need to invent your own language? Why oh why? Hashicorp also knows better. Remember Vagrant? Vagrant got it right with the DSL + you could always drop down to Ruby if you did something not covered by the DSL.
My advice to you: use whatever the cloud you are using has built it (cloudformation, deployment manager, etc).
> 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.
> 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.
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.
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.
> 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.
>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?
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.
I love your comment,"YOLO-ing" gave me a laugh, and a laugh at myself in some previously stressful/complex deployment periods. Terraform was not a friend there.
That said, I've worked on/with a team enabling some fairly advanced & streamlined capabilities across all three clouds because of Terraform. The abstraction matters, and ability to model scaled platform components and architectures as singular units is important. The open source community is great.
is the open source community great? Look at the open bugs. Some of them are old enough to go to school.
For extra lolz try killing the terraform process of pulling the network cable. Hilarity ensures and you’re gonna have a bad time recovering what it was doing.
There was a bug fixed few months ago. Until recently when you tried to destroy the infrastructure it started to undo what was actually deployed. Previously it was using the current hcl file.
Have you never had a failure with CloudFormation? Because when that happens you can’t see what’s going on and you often can’t get out of the situation without engaging support.
More often than not with Terraform, another apply will fix the problems you are complaining about. But if it doesn’t at least you have the power to fix it unlike with CloudFormation.
But ultimately whatever tools you use you will have trouble if you are unwilling to engage with them and learn how they work.
I gonna share something shocking here: but I have never seen Cloudformation crap out in a manner that was not consistent and clear. Usually it will either try until it succeeds or fail in a clear and predictable manner.
(I have been using AWS since forever and both Cloudformation and Terraform(sad panda) for years. I will preach the shortcomings of terraform to everyone that listens. I have rarely seen developers using it for something non-trivial and being happy about it)
Roll back is one reason I choose AWS Cloudformation over Terraform. And also I do not see the reason for Terraform in my use case as we run only on AWS. No point in not using AWS native tools.
When using Terraform you should think of your IaC as the plans to build or rebuild your infrastructure, not an extension. I built mine in a way where I can destroy all the infrastructure in a plan and then reapply. You don't have to worry about rollbacks when you can just rebuild everything without affecting your end service.
It isn't left broken per say, in fact you should be able to version the state and rollback to the previous state and have it remove whatever new resources were created when you re-apply.
I just take another approach which is if something doesn't work, then I'm able to quickly blow it away and re-deploy without affecting the end service by having the apply only target specific environments.
If it is half deployed it is broken, maybe in some cases service continues running, but in other will be broken.
The solution you mentioned relies on other tools and some manual work you need to do. Also with how TF works by default you might never be able to restore to exact same state as it was before.
CF when needs to replace a resource it first creates a new copy, and applies all changes if everything succeeds then it removes old resource, if it fails it rolls changes back.
You have an option that allows you to do that with a resource, but it's done individually per resource and it still isn't exactly the same thing.
I don't use CF, but how does it handle rolling back a delete (thus recreating a resource) and resource ARNs? Is it using some functionality not available to other tools?
I always found tf's lack of rollback ability, basically admitting there is no way to really rollback to the exact state, ARNs and all, so it isn't going to try.
>Is it using some functionality not available to other tools?
No, CloudFormation just postpones resource deletions towards the end of stack operations to allow successful operation rollbacks. Even the default replacement strategy is creating the new resource before deleting the old resource whenever possible for this reason:
Here is the error you get when it fails:
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.
If that error does not give you pause, I don't know what will. It's basically YOLO-ing it and in case it does not work you're on your own. It's also leaving you in whatever state and now you need to figure out what it managed to do, what didn't work and figure out how to 1) make it work 2) make terraform understand that it worked. Usually this happens at the worst time when you are deploying to production.
Do we want to talk about when plan "works" but it craps out on "apply"? Or about when it just loses tracks of resources.
HCL? A disaster. Why would you need to invent your own language? Why oh why? Hashicorp also knows better. Remember Vagrant? Vagrant got it right with the DSL + you could always drop down to Ruby if you did something not covered by the DSL.
My advice to you: use whatever the cloud you are using has built it (cloudformation, deployment manager, etc).