31–40 of 64 posts
One killer feature of Infrastructure as Code, be it terraform or any other is idempotence. You have to be careful not to run your bash script twice or you get another instance/vpc/loadbalancer or whatever. You run "terraform apply" twice and it does nothing on the second run. If you start implementing that in your shell scripts you start implementing terraform in bash.
Terraform was made for exactly the reason you stated ("single language for all kinds of cloud infrastructures") It was also made for non-developers to be able to deploy what someone else built "anywhere"
But using Terraform with $CLOUD implies that you are familiar with $CLOUD - then if you know $CLOUD and bash why would you need to use Terraform to work with that cloud? Also, as stated in a sibling comment, all the commands, expressions and capabilities of Terraform differ based on your $CLOUD, so in the end it's not that universal. In fact, it's not different from bash - bash is always the same, you just type `az`…
>In fact, it's not different from bash - bash is always the same, you just type `az` instead of `aws-cli`.
Terraform works on many platforms (https://developer.hashicorp.com/terraform/downloads)
Not all have (or default to) bash
Whereas Terraform is "the same" everywhere
This has absolutely not been my experience. I've worked with a few devs who might be curious to know how everything worked. Most devs I've worked with focus solely on the code they write.
I've also inherited many systems over the years and I'd take the ones managed with tf over bash every single time.
A non exhaustive list of what tf helps with.
1. Being able to know what has changed and what needs to change before you run
2. Managing infra outside of the large cloud providers and being able to combine the two
3. Quickly being able to add a new environment or region to an existing cluster
4. Some requirement has changed and some new policy/tool needs to be stitched in across all your environments
Terraform was made for exactly the reason you stated ("single language for all kinds of cloud infrastructures") It was also made for non-developers to be able to deploy what someone else built "anywhere"
But using Terraform with $CLOUD implies that you are familiar with $CLOUD - then if you know $CLOUD and bash why would you need to use Terraform to work with that cloud? Also, as stated in a sibling comment, all the commands, expressions and capabilities of Terraform differ based on your $CLOUD, so in the end it's not that universal. In fact, it's not different from bash - bash is always the same, you just type `az`…
I am using Terraform because using AWS directly was too cumbersome, and I'm happy with it.
Earlier quoted context omitted.
Ok here's a less friendly version: "The way AWS is implemented doesn't work for me" is a nightmare attitude for everyone on your team and an affront to your productivity. Look at the early (mid 2000s) AWS customer success stories and think about what it did for those companies. Accept the model and get your undifferentiated systems work done quickly.
I failed to express my take against Terraform: instead of fighting indeterministic nature of infrastructure, it was created to work around it. Why far more experienced engineers than I am came to the conclusion that playing along is better than actively fighting?
Earlier quoted context omitted.
Ok here's a less friendly version: "The way AWS is implemented doesn't work for me" is a nightmare attitude for everyone on your team and an affront to your productivity. Look at the early (mid 2000s) AWS customer success stories and think about what it did for those companies. Accept the model and get your undifferentiated systems work done quickly.
I failed to express my take against Terraform: instead of fighting indeterministic nature of infrastructure, it was created to work around it. Why far more experienced engineers than I am came to the conclusion that playing along is better than actively fighting?
An engineers job is to get stuff done and not fight an ideological battleground. The world is impure, and requires impure solutions. Terraform is a tool to get things done, and given the realities of managing stateful infrastructure it does a pretty good job of addressing the failure states of it.
Earlier quoted context omitted.
Future-proofing, I assume. Better to have things in Terraform now than to have to move them all later as you grow the application. Moving things into Terraform can be quite hard, since you essentially need to figure out how to reproduce the entire infrastructure from scratch.
YAGNI.
I don't think having a unified interface is the motivation behind Terraform. You still need to understand the underlying resources you are dealing with, Terraform doesn't abstract that at all. The big idea behind Terraform is procedural vs declarative. You can write scripts to bring up all of your infrastructure but what if one of your scripts fails in the middle? What parts of it actually went into effect and which didn't? Can you just re-run it or will the first part now fail because the infrastructure already exists? What if you have several engineers working on the same environment applying scripts that may interfere with one another? What if there was an incident and you made some manual changes and now production is out of sync with what is represented in the script? What if you made some complicated infrastructure changes and you broke something and want to bring everything back to exactly how it was before?
Declarative infrastructure answers all of those questions. It lets you keep track of what the current state of your infrastructure is, and what you want it to be. It automatically identifies areas where the two don't match up and serves as a forcing function for documenting changes to your infrastructure. Declarative infrastructure is more complicated than procedural because bringing up infrastructure is a procedural process so you need a tool to make it into a declarative one and that is not always easy. But if your team's needs get complex enough the tradeoff is well worth it. I honestly can't even imagine life without it.
As a bonus it makes it easy to ship complete infrastructure solutions as re-usable modules that you can compose.
> But in majority of the cases developers are very much aware of environments their code run on - they know that their containers are stored in ECR, ran in ECS, their data is stored in S3 and RDS. This has absolutely not been my experience. I've worked with a few devs who might be curious to know how everything worked. Most devs I've worked with focus solely on the code they write. I've also inherited many systems ov…