Hacker News new | ask | show | jobs
by srsqsonyl 1013 days ago
Can anyone explain the point of TF?

I’m sure there’s some 100% subjective, hallucinated value statement but never felt a reason to bother.

I’ve only ever used an AWS SDK and “saved state” to git in the form of my SDK scripts.

Switched from Python+boto to Go+SDK a few years ago rather than learn some DSL the Lindy effect clock was ticking on.

3 comments

- the situation: you build cloud infrastructure via CLI or console

- the problem: if something gets deleted, or if you make a bunch of changes and want to undo them, or if you need to make a change to a lot of stuff at once, or if you want to copy what you've built to a new region, how do you do it? or, if you're on a team, how do you as a team make and track changes to your cloud infrastructure?

- terraform as a solution: you describe your cloud infrastructure as yaml files. terraform can figure out what is different between what's in your cloud infrastructure and what your yaml files say it should look like. and, it can make changes to your cloud to e.g. build it from scratch, make wide-ranging changes, make a copy of it, etc.

- since your yaml files are code, you can also create a repo and do PRs to make and track changes to your cloud infrastructure as it evolves over time

Sometimes the detected differences are manual changes (“drift”) that shouldn’t have happened, and terraform will offer to reverse them.
Appreciate the answer. In hindsight my use of the word scripts was insufficient.

Looked at the TF code; my solution implements similar functionality to handle AWS CRUD ops. What I avoid is all the DSL parsing and such.

For me an AWS account is a struct with fields of AWS SDK resource types, which it seems is what TF resources map to (they handle a lot more so there’s more to it, but kind of sort of if I squint just right). Either going to duplicate the internal logic or DSL chunks per project, would rather avoid the context switch between syntax, “learning the TF ecosystem”.

Thanks again, though.

The value of DSL is that the same terraform can run things on your local ESX cluster. I imagine few shops need multiple provider support
What Terraform brings to the table for us is the capability of calculating the delta of "I want those resources" and "these resources are actually there" by having a separate state stored e.g. as JSON in S3 to compare your code, the world as it should be and how it actually is. That takes away reimplementing that.

Why just not writing idempotent resource creation? Terraform also uses this to calculate a "plan" that shows the diff of your changes with reality, which really helps to figure out what happens to your RDS when executing, especially when more abstraction (in form of Terraform modules) is involved.

We used Terraform also in a situation where writing custom code would be "prettier" but would have required to write this actual vs desired state code ourselves and could save us the work of doing so.

The DSL of Terraform is sometimes quite cumbersome though as it's derived JSON and not some actual programming language.

To your last point, yeah, I think Terraform gets really painful when you have to do something involving derived values in a loop. Also just computed values in general there is not a great story around (which is not necessarily terraforms fault, but rather a symptom of what you are provisioning).

A simple example of what I mean by computed values is that let’s say you want to provision a k8s cluster on top of a network. The k8s provider might want the network name/id which you could normally get by setting it upstream. The problem is you can’t plan the network creation and k8s cluster in a single pass because you don’t get the network name until it’s actually provisioned. You actually need to apply the network tf first to get the inputs you need to plan the cluster. Meaning not only do you need to run tf twice, you also can’t E2E plan infra provisioning

If anyone has a solution/pattern for the above (or more generally how to chain these modules together when this limitation exists) I’m all ears

Can your example be solved by having the k8s cluster resource reference the network resource’s “name” attribute?

Doing that allows Terraform to create both resources in one plan/apply step, and it also helps Terraform understand the dependency between the resources so that they are created in the correct order.

My hobby solution was to represent an environment as an ordered graph that you can spin up.

https://devops-pipeline.com/

The point of TF is working with your infrastructure declaratively. You write down what you want, how it should be integrated with each other, how IAM should be set up. And then that is what you get.

For me using terraform is quicker than clicking things up or using CLI even when initially developing things, as if something goes wrong I can just destroy the state and re-apply the terraform config.

> For me using terraform is quicker than clicking things up or using CLI even when initially developing things

then you obviously have every single resource name, required values, and relationships between them memorized because in my experience post-facto encoding of something into TF can be valuable to the organization but trying to _discover_ the providers, iam, required fields to achieve a desired outcome is crawling over broken glass as compared to click-ops-ing something in place

Hell, there's even a browser extension to record the AWS calls so one can at least see what was done later for replay, but with GCP they have their own sneaky RPC something-something encoding so that idea's off the table

> then you obviously have every single resource name, required values, and relationships between them memorized

I don't.

> crawling over broken glass as compared to click-ops-ing something in place

I do not experience reading the terraform provider docs like crawling over broken glass but okay.

I program with Python also and it's not like I have memorized every class and function either, but still, I and millions of other people somehow manage get by.