Hacker News Reader

Comment by jasonhansel | Hacker News Reader

It's probably overkill for your use case. If you're on AWS you can stick to CloudFormation; with something this simple, you can indeed just (as you suggest) use a bash script.

But a lot of applications have infrastructure far, far more complex than a single service running in a container and S3/RDS. It may involve a large number of lambdas, networks, API gateways, firewalls, proxies, certificates, etc.

Past a certain point, you need a way of managing all that complexity, keeping things consistent across environments/regions, ensuring all infrastructure changes are tracked and audited, and making it easier to update lots of resources at once, among other things. That's where Terraform helps.

View on HN

> If you're on AWS you can stick to CloudFormation

I would caution against this, even if you solely work on AWS. CloudFormation is much, much slower and has failure modes where it can take hours before the CF service returns to a manageable state. This is slightly better now that they added the ability to ignore failures so you can delete resources manually and then restart the CF rollback process but it’s still much more prone to getting into states where someone knows exactly what needs to be done but the tool won’t let them do it.

We switched to Terraform about half a decade ago over that and it was such a great removal of friction from your development cycle. I tried a small CF project last summer and had to help multiple experienced AWS users with the same class of problems within a week.

Then I guess it's a question to the startup I'm working at - why in the world did they overcomplicate so much stuff when in fact we have constant number of environments, workers, load balancers? In fact, every engineer in the company is very much aware on how our system operates and (I believe) could easily imitate whatever Terraform does with simple scripts.

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.

You won't need it. But you'll probably want it, since at most start-ups complexity grows over time.

Sounds like lack of knowledge and experience to start glueing random stuff to make things over complicated.

Unless your startup is wildly successful, which everyone is incentivized into believing. What you described sounds less like a Terraform problem and more like a complex infra problem.

Your startup probably has better things for engineers to do than the job Terraform does in determining what state changes to make.

I mean, the engineers could probably convert source into machine into machine instructions, too, but I bet your company would rather leave that to a compiler so that they could work on product.

If you have the skills on hand then I think it's worth doing TF off the bat, otherwise it's probably better to wait until you have the requisite pain/motivation to learn. It's a pain in the ass to learn how to do TF _initially_ but not bad to do after you learn, and going forward you avoid a lot of "oh wtf just happened" moments during deployments/infrastructure changes.

Reply on news.ycombinator.com