undefined | Better HN

0 pointssepositus1y ago0 comments

This is probably inaccurate, but it seemed like they wrote it off as a safe move, with their main competitor, Pulumi, getting away with it.

However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a decent way to scale costs appropriately.

I hate it, though. It's user-hostile and forces people to adopt anti-patterns to limit costs.

0 comments

sofixa1y ago

> forces people to adopt anti-patterns to limit costs

The previous pricing model, per workspace, did the same. Pricing models are often based on "value received", and therefore often can be worked around with anti-patterns (e.g. you pay for Microsoft 365 per user, so you can have users share the same account to lower costs).

sausagefeet1y ago

> Every resource necessitates API calls that consume compute resources

In that world, I think it'd make more sense to charge per run-time second of performing an operation. I understand the argument you are making but the issue is you get charged even if you never touch that resource again via an operation.

It might make sense if TFC did something, anything, with those resources between operations to like...manage them. But...

hiatus1y ago

> However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a decent way to scale costs appropriately.

That would make sense if you paid per API call to any of the cloud providers.

sepositusOP1y ago

What happens when you run `terraform apply`? Arguably, a lot of things, but at its core it:

- Computes a list of resources and their expected state (where computation is generally proportional to the number of resources).

- Synchronizes the remote state by looking up each of these resources (where network ingress/egress is proportional to the number of resources).

- Compares the expected state to the remote state (again, where computation is generally proportional to the number of resources).

- Executes API calls to make the remote state match the expected state (again, where network ingress/egress is proportional to the number of resources).

- Stores the new state (where space is most certainly proportional to the number of resources)

This is a bit simplified, but my point is that in each of the five operations, the number of resources can be used as a predictor for the consumed compute resources (network/cpu/memory/disk). A customer with 10k resources is necessarily going to consume more compute resources than one with 10 resources.

glenngillen1y ago

you can probably get a sense of it based on your own usage of terraform and the log output (or the time various resources take to get managed in the Terraform Cloud/Enterprise UI). I think in the majority of cases you'll see that the bulk of the compute time is actually network bound, not because of the number of resources, just because the server at the other end (AWS, Azure, GCP, etc.) is doing a lot of work. I know in some cases things like SQL Server Clusters on Azure can take literally hours to provision. Terraform will spend that "compute" time sitting there waiting, it's not actually doing much resource intensive though.

And then at the end as you said "stores the new state". Which is basically a big JSON file. 10 resources? 1M resources? I'll leave you to work out how much it probably costs to save a JSON file of that size somewhere like S3 ;)

hiatus1y ago

In absolute terms, I agree with you. But in practical terms I would wager it is negligible.

1 more reply

cruffle_duffle1y ago

Sure but it’s calling those service apis directly. The “hard work” is not being done by the client making those calls. Presumably.

j / k navigate · click thread line to collapse

0 comments

sofixa1y ago

> forces people to adopt anti-patterns to limit costs

sausagefeet1y ago

> Every resource necessitates API calls that consume compute resources

It might make sense if TFC did something, anything, with those resources between operations to like...manage them. But...

hiatus1y ago

That would make sense if you paid per API call to any of the cloud providers.

sepositusOP1y ago

What happens when you run `terraform apply`? Arguably, a lot of things, but at its core it:

- Computes a list of resources and their expected state (where computation is generally proportional to the number of resources).

- Synchronizes the remote state by looking up each of these resources (where network ingress/egress is proportional to the number of resources).

- Compares the expected state to the remote state (again, where computation is generally proportional to the number of resources).

- Executes API calls to make the remote state match the expected state (again, where network ingress/egress is proportional to the number of resources).

- Stores the new state (where space is most certainly proportional to the number of resources)

glenngillen1y ago

hiatus1y ago

In absolute terms, I agree with you. But in practical terms I would wager it is negligible.

1 more reply

cruffle_duffle1y ago

Sure but it’s calling those service apis directly. The “hard work” is not being done by the client making those calls. Presumably.

j / k navigate · click thread line to collapse