Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terraform 0.15 General Availability

hashicorp.com

Post reply on HN
Print view View original

211–220 of 239 posts

Re: Terraform 0.15 General Availability

#211

Post by xyzzy123 »

k__ wrote: post #201
xyzzy123 wrote: post #71

Earlier quoted context omitted.

So regular CDK is basically a program-driven CFN generator. Pulumi has a similar model where you build a resource graph at runtime BUT it's also got the execution engine built-in to the tool. What this means in practice is that you can create resources (like a kube cluster) and then use them as providers (e.g provision state tracked resources with kube api) all in the same operation. You can also (in your infracode o…

I don't think I 100% understand. Could you elaborate a bit more? Let's say I have an app with API Gateway, Lambda, and DynamoDB. I would provision them with one of those tools CDK or Pulumi. How would these tools differ in their provisioning steps?

You wouldn't see much _practical_ difference between CDK and Pulumi (or Terraform!) for that use-case. The workflow would feel almost identical.

Under the hood different things are happening.

Your CDK program would run with all the resources you declared. That would generate CloudFormation script(s) that get submitted to the CloudFormation service for evaluation. The CloudFormation service (running inside AWS) is the "execution engine" and is responsible for creating and tracking the state of your resources.

Pulumi would run your code, build an object graph, then do the "execution" itself - invoke all the required AWS API calls to create your resources (the API Gateway, the Lambda, etc etc) from where the CLI is running. The CLI would also be writing out all the resource state to somewhere.

The tradeoffs are in line with what you might expect. The Pulumi approach is more powerful, but you "own" more of the complexity since it lives on your side of the responsibility boundary.

Some people prefer AWS to be the execution engine; they feel it's more reliable to let AWS provision resources and keep track of state. They like it that AWS is responsible and will fix bugs.

Others prefer the increased control of "owning" the execution engine. This means being able to debug it or extend it with third party or custom providers that let you provision new resource types. They're happy that they don't need to wait for AWS to fix things, they can do it themselves if they have to.

This is not the only difference between the two tools but it is one of the most fundamental ones.

Re: Terraform 0.15 General Availability

#212

Post by 74d-fe6-2c6 »

cmclaughlin wrote: post #25

On a related note, CDK for Terraform allows DevOps practitioners to use a variety of programming languages instead of HCL. I've really enjoyed modeling my AWS environments with Python using Terraform only as the engine. More info here: https://github.com/hashicorp/terraform-cdk

Why would you use CDK with Terraform instead of CDK with CloudFormation? The latter seems like a more reasonable choice as it is native to AWS.

Re: Terraform 0.15 General Availability

#213

Post by k__ »

xyzzy123 wrote: post #211
k__ wrote: post #201

Earlier quoted context omitted.

I don't think I 100% understand. Could you elaborate a bit more? Let's say I have an app with API Gateway, Lambda, and DynamoDB. I would provision them with one of those tools CDK or Pulumi. How would these tools differ in their provisioning steps?

You wouldn't see much _practical_ difference between CDK and Pulumi (or Terraform!) for that use-case. The workflow would feel almost identical. Under the hood different things are happening. Your CDK program would run with all the resources you declared. That would generate CloudFormation script(s) that get submitted to the CloudFormation service for evaluation. The CloudFormation service (running inside AWS) is the…

Ah, thanks for this explanation!

Re: Terraform 0.15 General Availability

#214

Post by cmclaughlin »

tribaal wrote: post #206
cmclaughlin wrote: post #144

Earlier quoted context omitted.

I tried Pulumi with Python and kept running into show stopper bugs.

I'm currently about to switch to pulumi/python (we're a python show). What showstoppers did you run into? Any insight welcome if that prevents me from hitting a wall I've not seen yet :)

My first project was trying to deploy a Redshift cluster. It flat out didn’t work. Did 2-3 calls with their tech sales before giving up on it. And then cdktf came out shortly after that.

Re: Terraform 0.15 General Availability

#215

Post by cmclaughlin »

74d-fe6-2c6 wrote: post #212
cmclaughlin wrote: post #25

On a related note, CDK for Terraform allows DevOps practitioners to use a variety of programming languages instead of HCL. I've really enjoyed modeling my AWS environments with Python using Terraform only as the engine. More info here: https://github.com/hashicorp/terraform-cdk

Why would you use CDK with Terraform instead of CDK with CloudFormation? The latter seems like a more reasonable choice as it is native to AWS.

CloudFormation is really slow and lags behind in supporting all AWS features.

Terraform is super fast, has great docs and vast coverage for managing just about any type of cloud resource.

Re: Terraform 0.15 General Availability

#216

Post by k__ »

xyzzy123 wrote: post #211
k__ wrote: post #201

Earlier quoted context omitted.

I don't think I 100% understand. Could you elaborate a bit more? Let's say I have an app with API Gateway, Lambda, and DynamoDB. I would provision them with one of those tools CDK or Pulumi. How would these tools differ in their provisioning steps?

You wouldn't see much _practical_ difference between CDK and Pulumi (or Terraform!) for that use-case. The workflow would feel almost identical. Under the hood different things are happening. Your CDK program would run with all the resources you declared. That would generate CloudFormation script(s) that get submitted to the CloudFormation service for evaluation. The CloudFormation service (running inside AWS) is the…

Nice.

Does Pulumi support stuff like Cloudflare Workers, FaunaDB, or Auth0?

Re: Terraform 0.15 General Availability

#217

Post by mbushey »

dkdk8283 wrote: post #204
sali0 wrote: post #153

So much hate ITT for such a great tool. Terraform is definitely not perfect but it's still one of my favorite tools, solely because of the amount of efficiency gained from learning it. Yes HCL is not perfect, but it is definitely adequate for a lot of applications. IMO, Hashicorp makes some of the most well thought out tools and I am grateful of their attitude towards open source.

I’ve preferred cloud formation for many years. the amount of time I spend debugging problems related to TF is infuriating. at least with aws.

Terraform makes me happy, I use it daily on AWS and GCP. I can't stand Cloud Formation.

Re: Terraform 0.15 General Availability

#218

Post by hamandcheese »

0xbadcafebee wrote: post #21
mitchellh wrote: post #11

Earlier quoted context omitted.

I'm one of the HashiCorp founders. Terraform 0.11 to 0.12 is by far the most difficult of the versions to upgrade between. I am really sorry about that. The other upgrades should be relatively minor as long as you read and follow the upgrade guides and upgrade one minor version at a time (0.11 => .12 => .13 etc.). There are rough edges for very specific cases but most of our customers were able to upgrade from 0.12 t…

Our teams have something like 100,000 LOC in Terraform 0.12, and it's not all in one big monorepo. At that scale there is no such thing as a relatively minor version upgrade. We want to upgrade to get away from some persistent 0.12 bugs, but we literally don't have the time. We have to change all of the code, and then test every single project that uses that code in non-prod, and pray that the testing finds most of t…

> and it's not all in one big monorepo

There's your first problem.

Re: Terraform 0.15 General Availability

#219

Post by aprdm »

darthrupert wrote: post #152
aprdm wrote: post #99

Earlier quoted context omitted.

The jump from what you mentioned in paragraph 2 to 3 is not necessarily Terraform. You can use other tools, like Ansible, that IMO have a much better framework than Terraform. I use Terraform for extremely simple stuff that is easy to destroy/recreate. Projects of bigger scale IMO are better served with Ansible and friends.

No, Ansible is not good for this. It's good for maintaining clusters of hosts, but its stateless nature makes it close to worthless for infrastructure.

Well I guess I beg to differ. Been creating and managing 10ks of hosts across multiple on prems datacenters and clouds for some time now.

Re: Terraform 0.15 General Availability

#220

Post by aprdm »

themacguffinman wrote: post #128
aprdm wrote: post #99

Earlier quoted context omitted.

The jump from what you mentioned in paragraph 2 to 3 is not necessarily Terraform. You can use other tools, like Ansible, that IMO have a much better framework than Terraform. I use Terraform for extremely simple stuff that is easy to destroy/recreate. Projects of bigger scale IMO are better served with Ansible and friends.

I'm no tooling expert but that seems like the opposite of what you should use Terraform for. Imperative frameworks like Ansible are basically fancy ways to organize and execute custom scripts, you still have to implement your own custom state management logic in Ansible commands/scripts. With larger & more complex infrastructure, you want to do this as little as possible because it's hard to consistently get it right…

Ansible has a bunch of declarative modules. Writing imperative Ansible should basically never happen. My team maintains 50-80 galaxy_roles and it's super rare that we have to build any shared galaxy role on top of imperative logic.
Post reply on HN