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

Infrastructure Manager: Provision Google Cloud Resources with Terraform

cloud.google.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#51

Post by hughesjj »

shepherdjerred wrote: post #40
x86x87 wrote: post #34

Earlier quoted context omitted.

CDK uses CloudFormation under the hood.

Is that really relevant? CloudFormation is just another primitive at this point. It's not much different from high-level code compiling down to machine code. The benefit of writing high level code isn't that machine code is entirely gone. The benefit is instead that as a user you can mostly forget that machine code exists.

Sometimes it does appear as a leaky abstraction. I want to say for example secrets storage support as a parameter

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#52

Post by srsqsonyl »

mef wrote: post #43
srsqsonyl wrote: post #42

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.

- 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 sol…

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.

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#53

Post by Jka9rhnDJos »

type_Ben_struct wrote: post #8

Licensing decision aside, I don’t feel a lot of sympathy for Hashicorp here. I think this is different than other scenarios where big MSP’s sell tools based 99% or open source software. This service will largely be used for deployments on Google Cloud, for which Google invests a lot of development effort in maintaining their own provider. It’s not like there’s not already significant contribution from Google to the c…

This isn’t really a service. All it does is deploy an infrastructure template into your GCP project. It won’t largely be for deployments on Google Cloud. It’s for automating Terraform, and whatever providers the customer wants to use.

https://cloud.google.com/infrastructure-manager/docs/view-re...

You, the customer, pay for everything deployed, and Google just pre-connects it to all their services for monitoring and maintenance. It would be like if Route53 on AWS was free, but it deployed a VM in your account, added gateways and nats, opened ports, etc., so that it all ran on discrete infrastructure for just you and you got charged for everything and had to do all the scaling.

If you’ve used their Apache Airflow product (Cloud Composer), it’s basically the same thing. With Cloud Composer, they are setting up an Airflow node and cluster on your behalf, in your account, that you pay for, and connecting it to their services.

This is no different than going to a consulting company and asking them to setup and maintain a Terraform automation platform in your account., which Hashicorp said was allowed. Google isn’t reselling it as a product. They’re setting it up on their platform on your behalf and giving it to you.

And there’s no reason you couldn’t switch it out to OpenTF.

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#54

Post by pfix »

srsqsonyl wrote: post #42

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.

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.

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#55

Post by anuraaga »

This seems likely a partnership between Google and Hashicorp, from what I understand most GCP integrations like redis are actually partnerships rather than just running the OSS independently. Potential license and trademark implications seems like it would be a particularly bad time to try the latter with Terraform.

As others have mentioned, this is not all that useful of a service - it doesn't seem to even have the concept of a "plan" let alone any approval system and seems to only allow for the most basic of workflows. Given that TF by default will store state in a bucket with true locking, I can't come up with any potential benefit this provides vs using Terraform directly.

The main question is whether this will be improved in the future or is intentionally just "Terraform Trial Edition" with terms of partnership preventing anything encroaching on Terraform Cloud. Perhaps for the former, the trial is important to understand usage to better inform revenue sharing for a future improved product.

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#56

Post by anyoneamous »

Demiurge wrote: post #49
anyoneamous wrote: post #7

Earlier quoted context omitted.

I see a roughly even split of people using CFn, Terraform and (Python) CDK. AWS shot themselves in the foot by making the Python version of CDK second-tier after Typescript; IaC is still done by DevOps people far more often than application people, and DevOps people use Python. Another gripe is the number of services and new features which launch without CFn support, which also blocks CDK support; when Terraform supp…

> Python version of CDK second-tier after Typescript What? It's not second-tier at all, every single feature in Python is in sync with TypeScript, the library versions are in sync, and the docs for all the languages are auto-generated. They're not second-tier, they're 100% single tier.

IME quite a few of those auto-generated docs (mostly the examples) have slight incorrectness, where the code snippet is a mangled mix of Python and TS.

Also, the tooling you need to drive CDK is all TS-based, which means I now need to think about NPM and Node versions occasionally, which are not relevant in any other part of my workflow.

Admittedly as someone in scientific computing I am unusually far from the JS/TS ecosystem - but all I can tell you is that it feels second tier as a user.

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#57

Post by reacharavindh »

cachvico wrote: post #44
diarrhea wrote: post #29

Earlier quoted context omitted.

I can’t help but feel… sad about this. I only recently picked up Terraform and am astounded that this is what goes as coding in the infrastructure world. I was coming from Ansible so there was only improvement to be had, but man did Terraform let me down so far. It (well, the provider) doesn’t validate fields until apply. That’s just so… sad. How is that acceptable? It’s like a car without a steering wheel, and peopl…

You do a dry run first

How is a terraform plan different from a dry run? I always mentally mapped terraform plan == dry run to validate what changes will be made. Your comment throws a gauntlet into that understanding..

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#58

Post by friendzis »

srsqsonyl wrote: post #52
mef wrote: post #43

Earlier quoted context omitted.

- 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 sol…

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 r…

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

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#59

Post by solatic »

diarrhea wrote: post #29
abatilo wrote: post #26

Earlier quoted context omitted.

In my experience, running a plan is much less likely to catch a bad value than the AWS provider. Subjectively, the AWS provider will at least validate that fields have valid values during the plan step. The Google provider doesn't seem to validate actual values until apply, and then you get a failure

I can’t help but feel… sad about this. I only recently picked up Terraform and am astounded that this is what goes as coding in the infrastructure world. I was coming from Ansible so there was only improvement to be had, but man did Terraform let me down so far. It (well, the provider) doesn’t validate fields until apply. That’s just so… sad. How is that acceptable? It’s like a car without a steering wheel, and peopl…

It's not really Terraform's fault. Terraform provides the capability to do all kinds of validations before running an apply, but it's up to the providers to implement the validations. If the provider doesn't implement the validation, then it's not there.

It gets hairier when you delve into the details. The provider is typically an official provider that wraps some company's API, so that company ought to have a good set of validations, since it's their own API, right? Wrong. The team that writes the Terraform provider is typically different from the team that creates API methods, and the API methods themselves don't typically expose "dry-run" style functionality, so there's little for the team writing the Terraform provider to check. Meanwhile, the business doesn't care - the Terraform provider checkbox is already checked and validations/dry-running isn't a feature that affects revenue.

Re: Infrastructure Manager: Provision Google Cloud Resources with Terraform

#60

Post by flanked-evergl »

srsqsonyl wrote: post #42

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.

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.

Post reply on HN