4 ms·

Terraform is for specifying deterministic, idempotent results given a set of conditions and inputs. Music apps like Spotify and Apple Music are about whimsical

Terraform is for specifying deterministic, idempotent results given a set of conditions and inputs. Music apps like Spotify and Apple Music are about whimsical, serendipitous discovery independent of rational thought. At least, for me, anyway. The two are wholly incompatible. I'm shocked that this exists. It calls into question how I think of music streaming platforms, what I think they provide, and how I interact with them.

deleted 5y ago
[deleted]
0xbadcafebee 5y ago
Terraform is just an overcomplicated way to call APIs. It's not deterministic and idempotent, as if you're "doing it right" you don't even know what values it's going to apply until after it's applied them. It can't be idempotent because Terraform doesn't determine if an API call will succeed or fail or do the same thing or not, the SaaS API does. And if you change anything, it can trigger a destroy, a create-destroy, a destroy-create, a create, or a modify, all of which may fail if the provider's resource wasn't designed for that particular operation with those values, which you won't know until it actually happens. Debugging it is a nightmare, and the bizarre interaction with pretty shoddy and inconsistent providers makes it pretty lucky if your applies actually work. It's basically an annoying version of curl that has a DAG that you can't even make good use of. I wouldn't call it whimsical, but getting anything to work in Terraform consistently definitely requires serendipity.
- mauflows 5y ago
  > as if you're "doing it right" you don't even know what values it's going to apply until after it's applied them. It can't be idempotent because Terraform what do you mean by this? 'terraform apply' runs plan first, and tells me the diff from the expected state. Then it asks me if I want to reconcile it. I agree with the rest tho
  - 0xbadcafebee 5y ago
    Have you seen it say "Old Value X" -> (known after apply) ? If you use most of Terraform's features, a good deal of the new values are (known after apply). If any of a value requires looking something up at apply time - say, from a backend, a data source, a local, the creation/modification/deletion of a different resource, a name_prefix, an internal function, etc - Terraform can't (or more precisely, won't) tell you what the new value is or could be. So often you have no idea what the result is going to be until it's done.
  - lukevp 5y ago
    Not all values are known to you or terraform until after the apply. For example, on AWS, publishing a new version of lambda might have the ARN as known after apply since it includes the version # as part of the string. Or something like the calculated hash of an S3 object that would be known after apply. You can still reference these values in other parts of your terraform, and it will propagate the < ‘known after apply’ state there too. These dependencies are built into a graph to determine which items should be applied first, so all references to unknown data can be resolved in the correct order.
- lukevp 5y ago
  You’re correct in that it’s not deterministic or idempotent if the APIs are not, but this reads as very anti-terraform. The purpose is not to be easier than curl, but to express your infrastructure in code so you can check it into a project and automate the deployment process, keeping the code version of the infrastructure in line with what is deployed. Curl doesn’t do that in any way and isn’t at all a valid comparison to terraform. If you feel IaC as a whole is a pointless/useless endeavor, that’s a point to argue, but comparing terraform to curl in this way is ignoring the main value add of IaC.
  - 0xbadcafebee 5y ago
    What do you mean curl doesn't do that? Terraform is literally just calling a REST API. Curl also just calls a REST API. #!/bin/sh curl -d '{"some key": "value here"}' -H "X-Some-Header: Foo-Bar" https://some-aws-domain/some/rest/api Put that in Git; now you have Infrastructure as Code. IaC is not some holy scepter ordained to us by God. It's literally just a version-controlled list of commands that call SaaS APIs. It's not special or magical. And Terraform doesn't do it any better than a bunch of curls in a shell script. The only reason to use Terraform is it's a standard way for a large group of people to make changes to the same thing. But if an entire team standardized on a shell script full of curls, that would work just as well. (Better, actually, because you could actually have error handling, auto-healing, importing existing resources, checking if they exist before trying to apply changes... you know, things that are useful for IaC that Terraform does not do)
caymanjim 5y ago
> It calls into question how I think of music streaming platforms, what I think they provide, and how I interact with them. The Terraform provider isn't from Spotify. Some dude made it. Spotify offers an API that can be used for any integrations people come up with.
solatic 5y ago
> Terraform is for specifying deterministic, idempotent results given a set of conditions and inputs. No. Terraform is for manipulating state on the other side of an API, including orchestrating the state behind multiple different APIs such that those APIs will be "harmonious" for your use case. > Music apps like Spotify and Apple Music are about whimsical, serendipitous discovery independent of rational thought. At least, for me, anyway. The two are wholly incompatible. I beg to differ. If something changes, Terraform makes those changes visible to you, because it keeps notes on what it thought the state was on the other side of the API. For the right use case, being notified of those changes, and possibly deciding to do something else instead, is important.
glenngillen 5y ago
> Terraform is for specifying deterministic, idempotent results given a set of conditions and inputs. It’s not as reductive as that. Terraform can give you a consistent configuration experience. What exactly that configuration does is heavily context and provider dependent. As commenters elsewhere have pointed out there’s an especially common use case with pinning to an AWS AMI that meets a certain criteria. New AMI gets published and next time you apply it’ll get the new AMI. That’s not idempotent. Similarly, this Spotify flow would let implement something like a playlist that was dynamic, but refreshed only on your terms. The plan phase of a run would let you assess any playlist changes, if they’re an improvement you can apply. If you don’t like the change you abandon it and leave things as they are. A provider for a different stream service starts to unlock the potential for playlist portability. It doesn’t magically happen. But if you were managing all your playlists this way it would significantly reduce the effort to switch platforms.
Bayart 5y ago
I've used Spotify since the invitation phase, in 2008 or so, and never have I used it for discovery. Not to say that there isn't value in it, but there's more than one way to swing a sword.

deleted 5y ago

[deleted]

0xbadcafebee 5y ago

Terraform is just an overcomplicated way to call APIs. It's not deterministic and idempotent, as if you're "doing it right" you don't even know what values it's going to apply until after it's applied them. It can't be idempotent because Terraform doesn't determine if an API call will succeed or fail or do the same thing or not, the SaaS API does. And if you change anything, it can trigger a destroy, a create-destroy, a destroy-create, a create, or a modify, all of which may fail if the provider's resource wasn't designed for that particular operation with those values, which you won't know until it actually happens. Debugging it is a nightmare, and the bizarre interaction with pretty shoddy and inconsistent providers makes it pretty lucky if your applies actually work. It's basically an annoying version of curl that has a DAG that you can't even make good use of. I wouldn't call it whimsical, but getting anything to work in Terraform consistently definitely requires serendipity.

mauflows 5y ago
> as if you're "doing it right" you don't even know what values it's going to apply until after it's applied them. It can't be idempotent because Terraform what do you mean by this? 'terraform apply' runs plan first, and tells me the diff from the expected state. Then it asks me if I want to reconcile it. I agree with the rest tho
- 0xbadcafebee 5y ago
  Have you seen it say "Old Value X" -> (known after apply) ? If you use most of Terraform's features, a good deal of the new values are (known after apply). If any of a value requires looking something up at apply time - say, from a backend, a data source, a local, the creation/modification/deletion of a different resource, a name_prefix, an internal function, etc - Terraform can't (or more precisely, won't) tell you what the new value is or could be. So often you have no idea what the result is going to be until it's done.
- lukevp 5y ago
  Not all values are known to you or terraform until after the apply. For example, on AWS, publishing a new version of lambda might have the ARN as known after apply since it includes the version # as part of the string. Or something like the calculated hash of an S3 object that would be known after apply. You can still reference these values in other parts of your terraform, and it will propagate the < ‘known after apply’ state there too. These dependencies are built into a graph to determine which items should be applied first, so all references to unknown data can be resolved in the correct order.
lukevp 5y ago
You’re correct in that it’s not deterministic or idempotent if the APIs are not, but this reads as very anti-terraform. The purpose is not to be easier than curl, but to express your infrastructure in code so you can check it into a project and automate the deployment process, keeping the code version of the infrastructure in line with what is deployed. Curl doesn’t do that in any way and isn’t at all a valid comparison to terraform. If you feel IaC as a whole is a pointless/useless endeavor, that’s a point to argue, but comparing terraform to curl in this way is ignoring the main value add of IaC.
- 0xbadcafebee 5y ago
  What do you mean curl doesn't do that? Terraform is literally just calling a REST API. Curl also just calls a REST API. #!/bin/sh curl -d '{"some key": "value here"}' -H "X-Some-Header: Foo-Bar" https://some-aws-domain/some/rest/api Put that in Git; now you have Infrastructure as Code. IaC is not some holy scepter ordained to us by God. It's literally just a version-controlled list of commands that call SaaS APIs. It's not special or magical. And Terraform doesn't do it any better than a bunch of curls in a shell script. The only reason to use Terraform is it's a standard way for a large group of people to make changes to the same thing. But if an entire team standardized on a shell script full of curls, that would work just as well. (Better, actually, because you could actually have error handling, auto-healing, importing existing resources, checking if they exist before trying to apply changes... you know, things that are useful for IaC that Terraform does not do)

caymanjim 5y ago

> It calls into question how I think of music streaming platforms, what I think they provide, and how I interact with them. The Terraform provider isn't from Spotify. Some dude made it. Spotify offers an API that can be used for any integrations people come up with.

solatic 5y ago

> Terraform is for specifying deterministic, idempotent results given a set of conditions and inputs. No. Terraform is for manipulating state on the other side of an API, including orchestrating the state behind multiple different APIs such that those APIs will be "harmonious" for your use case. > Music apps like Spotify and Apple Music are about whimsical, serendipitous discovery independent of rational thought. At least, for me, anyway. The two are wholly incompatible. I beg to differ. If something changes, Terraform makes those changes visible to you, because it keeps notes on what it thought the state was on the other side of the API. For the right use case, being notified of those changes, and possibly deciding to do something else instead, is important.

glenngillen 5y ago

> Terraform is for specifying deterministic, idempotent results given a set of conditions and inputs. It’s not as reductive as that. Terraform can give you a consistent configuration experience. What exactly that configuration does is heavily context and provider dependent. As commenters elsewhere have pointed out there’s an especially common use case with pinning to an AWS AMI that meets a certain criteria. New AMI gets published and next time you apply it’ll get the new AMI. That’s not idempotent. Similarly, this Spotify flow would let implement something like a playlist that was dynamic, but refreshed only on your terms. The plan phase of a run would let you assess any playlist changes, if they’re an improvement you can apply. If you don’t like the change you abandon it and leave things as they are. A provider for a different stream service starts to unlock the potential for playlist portability. It doesn’t magically happen. But if you were managing all your playlists this way it would significantly reduce the effort to switch platforms.

Bayart 5y ago

I've used Spotify since the invitation phase, in 2008 or so, and never have I used it for discovery. Not to say that there isn't value in it, but there's more than one way to swing a sword.