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

Yoke: Infrastructure as code, but actually

xeiaso.net

Post reply on HN
Print view View original

51–60 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#51

Post by cedws »

WatchDog wrote: post #22

I'm quite happy with CDK[0]. My experience is only with the main AWS cloudformation based version of CDK, although there is also CDK for terraform, which supports any resource that terraform supports, although some of what I'm about to say is not applicable to that version. What I like about CDK, is that you can write real code, and it supports a wide range of languages, although typescript is the best experience. Pr…

In your experience how often have you had template builds succeed but then fail at apply time? This kind of issue is what I find most frustrating about IaC today, your 'code' 'compiling' means nothing because all of the validations are serverside, and sometimes you won't find out something's wrong until Terraform is already half done applying. I want to be able to declare my infrastructure, be able to fully validate it offline, and have it work first try when I apply it.

Re: Yoke: Infrastructure as code, but actually

#52

Post by __turbobrew__ »

> This is not code. This is configuration.

It is all configuration (data) my friend. At the end of the day the internet and the services which connect it are all based off hard codes somewhere.

How do you think Google enumerates all their datacenters? You bet ya there is a magic config file you have to update to add new datacenters and from there the automation kicks off the infrastructure based upon the contents of the config file, the configuration is still there.

Re: Yoke: Infrastructure as code, but actually

#53

Post by taberiand »

kacesensitive wrote: post #49
taberiand wrote: post #48

Earlier quoted context omitted.

You can't do it if you have the instances created with auto-scaling groups of course. But nobody would think you could, that's runtime not infra. With Terraform you are supposed to have multiple coupled state files, with a tree structure of references, so that eg the state file containing the DNS can reference the previously applied state file that created the instances You are supposed to run terraform apply in a se…

At that point, you’re conceding the exact limitation I was pointing out. Terraform can't handle truly dynamic infrastructure changes within a single plan because its execution model is declarative, not imperative. Saying "nobody would think you could" just acknowledges that Terraform lacks the flexibility of real code—because if it were actual code, you'd be able to handle this inline rather than orchestrating multip…

The point is terraform can do it, and it does it well. Just because you don't want to use Terraform properly doesn't mean it's bad at what it does.

Using "a real programming language" to do the infra still has to solve the same issues faced by terraform. Using a programming language to define infra doesn't solve the auto scaling DNS issue, for example, you'll be using lambdas to create the dns either way. It also doesn't inherently solve coordination of the resource deployment, you still need to organise your code into modules and ensure the order of execution.

If you think Terraform is the problem here you're blaming the tool for a failure of process and understanding

Re: Yoke: Infrastructure as code, but actually

#55

Post by kacesensitive »

taberiand wrote: post #53
kacesensitive wrote: post #49

Earlier quoted context omitted.

At that point, you’re conceding the exact limitation I was pointing out. Terraform can't handle truly dynamic infrastructure changes within a single plan because its execution model is declarative, not imperative. Saying "nobody would think you could" just acknowledges that Terraform lacks the flexibility of real code—because if it were actual code, you'd be able to handle this inline rather than orchestrating multip…

The point is terraform can do it, and it does it well. Just because you don't want to use Terraform properly doesn't mean it's bad at what it does. Using "a real programming language" to do the infra still has to solve the same issues faced by terraform. Using a programming language to define infra doesn't solve the auto scaling DNS issue, for example, you'll be using lambdas to create the dns either way. It also doe…

The core issue isn't whether Terraform can do it—it's how it does it. You're describing a workflow that requires multiple state files, external tools like Terragrunt, and sequential terraform apply runs to work around the fact that Terraform itself lacks imperative, runtime-driven logic. That’s not "using Terraform properly"—that’s compensating for its limitations.

And sure, using a general-purpose language doesn’t magically eliminate coordination problems, but it does give you far more control. If I were using something like Pulumi or CDK, I wouldn’t need to hack around Terraform’s static graph by splitting state files and manually sequencing deployments. I could express logic directly in code—dynamically querying instance IDs, handling autoscaling changes, and updating DNS records inline, without requiring an entirely separate execution step.

So no, this isn't a "failure of process and understanding"—it's just recognizing that Terraform’s declarative model is great for static infrastructure but falls short when dealing with truly dynamic scenarios. If you think its workflow is fine, that’s cool—but don’t pretend it doesn’t have real limitations just because you've built processes to work around them.

Re: Yoke: Infrastructure as code, but actually

#56

Post by WatchDog »

cedws wrote: post #51
WatchDog wrote: post #22

I'm quite happy with CDK[0]. My experience is only with the main AWS cloudformation based version of CDK, although there is also CDK for terraform, which supports any resource that terraform supports, although some of what I'm about to say is not applicable to that version. What I like about CDK, is that you can write real code, and it supports a wide range of languages, although typescript is the best experience. Pr…

In your experience how often have you had template builds succeed but then fail at apply time? This kind of issue is what I find most frustrating about IaC today, your 'code' 'compiling' means nothing because all of the validations are serverside, and sometimes you won't find out something's wrong until Terraform is already half done applying. I want to be able to declare my infrastructure, be able to fully validate…

I've had less such issues with CDK, versus raw cloudformation, or terraform, but it can still happen.

Re: Yoke: Infrastructure as code, but actually

#57

Post by habitue »

People are on here arguing that terraform is code, actually. Sure it is, but it's not a good general purpose programming language. It is a config language that grew some features from general purpose languages. It's clearly more pleasant to write that config in a real language

Re: Yoke: Infrastructure as code, but actually

#58

Post by akdor1154 »

Hill I will die on: Terraform being less expressive than a real language is a feature, not a drawback.

CDK/Pulumi/Yoke is optimised for being easy to write, but code should be optimised to be easy to READ.

Sure, cdk/pulumi/yoke lets you write the most clever and succinct construction you can compose in your favourite language.. however, whoever comes across your clever code next will probably want to hit you, especially if it's not a dev from your immediate team, and especially if you have succumbed to blurring the lines between your idk code and your app code.

If they instead come across some bog-standard terraform that maybe has a bunch of copy-paste and is a bit more verbose... Who cares? Its function will be obvious, there is no mental overhead needed.

On the flipside Helm templating is an absolute abomination and i would probably take anything over needing to immerse myself in that filth, maybe Yoke is worth a look after all. But the REAL answer is a real config language, still.

Re: Yoke: Infrastructure as code, but actually

#59

Post by liampulles »

akdor1154 wrote: post #58

Hill I will die on: Terraform being less expressive than a real language is a feature, not a drawback. CDK/Pulumi/Yoke is optimised for being easy to write, but code should be optimised to be easy to READ. Sure, cdk/pulumi/yoke lets you write the most clever and succinct construction you can compose in your favourite language.. however, whoever comes across your clever code next will probably want to hit you, especia…

As the Go proverb goes: "clear is better than clever". https://go-proverbs.github.io/

Re: Yoke: Infrastructure as code, but actually

#60

Post by liampulles »

In a previous project, I decided to write a Go program to template k8s YAML from "higher level" definitions of resources. It worked, but the mapping code ended up being more complex than I would have liked, and I think it was ultimately difficult to maintain.

Lesson for me was to think about infrastructure in terms of infrastructure, i.e. treat it as its own domain.

Post reply on HN