Live data from Hacker News

Yoke: Infrastructure as code, but actually

xeiaso.net

41–50 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#41

I think a majority of the rants about Terraform I read are written from the perspective of someone managing inherently ephemeral infrastructure - things that are easily disposed of and reprovisioned quickly . The author of such a critique is likely managing an application stack on top of an account that someone else has provided them, a platform team maybe. CDK probably works for you in this case. Now, if you belong…

> Horses for courses.

I think with YMMV, these are the two most important things we need to keep in our mind. With plethora of technologies and similar tools, we generally read the tin superficially but not the manual, and we declare "This is bollocks!".

Every tool is targeted towards a specific use and thrive in specific scenarios. Calling a tool bad for something not designed for is akin to getting angry to your mug because it doesn't work as well when upside down [0].

[0]: https://i.redd.it/mcfym6oqx5p11.jpg

Re: Yoke: Infrastructure as code, but actually

#42
This is not code. This is configuration.

FWIW we've been working on letting you declare data in YSH, a new Unix shell.

So you can arbitrarily interleave code and data, with the same syntax. The config dialect is called "Hay" - Hay Ain't YAML.

Here's a demo based on this example: https://github.com/oils-for-unix/blog-code/blob/main/hay/iac...

It looks almost the same as HCL (although I think this was convergent evolution, since I've actually never used Terraform):

    # this is YSH code!
    echo 'hello world'

    Data aws_route53_zone cetacean_club { 
      name = 'cetacean.club.'
    }

    Resource aws_route53_record A {
      zone_id = data.aws_route53_zone.cetacean_club.zone_id
      name    = "ingressd.$[data.aws_route53_zone.cetacean_club.name]"
      type    = 'A'
      ttl     = "300"
    }
And then the stdout of this config "program" is here - https://github.com/oils-for-unix/blog-code/blob/main/hay/out...

It can be serialized to JSON, or post-processed and then serialized

---

Then I show you can wrap Resource in a for loop, as well as parameterize it with a "proc" (procedure).

    make-resource (12)
    make-resource (34)
    if (true) {
      make-resource (500)
    }
This is all still in progress, and can use feedback, e.g. on Github. (This demo runs, but it relies on a recent bug fix.)

The idea is not really to make something like Terraform, but rather to make a language with metaprogramming powerful enough to make your own "dialects", like Terraform.

---

I wrote a doc about Hay almost 3 years ago - Hay - Custom Languages for Unix Systems - https://oils.pub/release/0.27.0/doc/hay.html

Comments - https://lobste.rs/s/phqsxk/hay_ain_t_yaml_custom_languages_f...

At that time, Oils was a slow Python prototype, but now it's fast C++! So it's getting there

The idea of Oils is shell+Python+JSON+YAML, squished together in the same language. So this works by reflection and function calls, not generating text ("Unix sludge"). No Go templates generating YAML, etc.

Re: Yoke: Infrastructure as code, but actually

#43
post #4

I ditched Terraform years ago and just interact with the raw cloud provider SDKs now. It's much easier to long-term evolve actual code and deal with weird edgecases that come up when you're not in beholden to the straight jacket that is configuration masquerading as code. Oh yea, and we can write tests for all that provisioning logic too.

I’ve been thinking about this for a long time. But doesn’t it brings a host of other issues? For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created? I need to make a small change, how do I know what parts of my scripts to run?

Re: Yoke: Infrastructure as code, but actually

#44

Speaking of IAC- I have an existing GCP project with some basic infra (service accounts, cloud run jobs, cloud build scripts, and databases) what is the best tool to _import_ all of this into IAC. The only real tool I’ve found is terraformer. I have no dog in the race regarding tooling e.g if my output is Pulumi, terraform, or just straight YAML. I’m just looking to “codify” it. Any suggestions from experience?

Just go with plain Terraform. You can check the docs for the GCP provider to see if the resources you want to manage are "importable" into the Terraform state file; they usually are and you'll see a section at the bottom of each resources documentation page showing you how to do this. e.g. https://registry.terraform.io/providers/hashicorp/google/lat... Your process will be - 1. Write TF configuration approximating wh…

You don't need to write all the tf upfront for existing resources.

Use `import` resources in a .tf file (I like to just call it imports.tf) and run `terraform plan -generate-config-out=imported.tf`

That will dump the tf resources - often requires a little adjustment to the generated script, but it's a huge time saver

Re: Yoke: Infrastructure as code, but actually

#45
post #4

I ditched Terraform years ago and just interact with the raw cloud provider SDKs now. It's much easier to long-term evolve actual code and deal with weird edgecases that come up when you're not in beholden to the straight jacket that is configuration masquerading as code. Oh yea, and we can write tests for all that provisioning logic too.

I’ve been thinking about this for a long time. But doesn’t it brings a host of other issues? For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created? I need to make a small change, how do I know what parts of my scripts to run?

You write code to do these things? If there's a requirement for you to be able to do such a thing make it a feature, implement it with tests and voila, no different than any other feature or bug you work on is it?

Re: Yoke: Infrastructure as code, but actually

#46
post #26

> If you're using a language like Go, you need to have either the Go compiler toolchain installed or prebuild binaries for every permutation of CPU architecture and OS that you want to run your infrastructure on. This doesn't scale well. This is exactly the approach that Terraform takes. Both Terraform and its providers are written in Go, which is a great language for this purpose because of GoReleaser and the ease o…

Hi. I think the article was just showing the example that IaC tools use configuration languages instead of code. Yoke is not a terraform replacement, and does not mention terraform anywhere its documentation.

It does sit at the same level as helm & timoni. It just takes a code-based approach to managing your cluster (which in turn can manage your infra but that wasn't the larger point).

Re: Yoke: Infrastructure as code, but actually

#47

If you really do think that Terraform is code, then go try and make multiple DNS records for each random instance ID based on a dynamic number of instances. Correct me if I'm wrong, but I don't think you can do that in Terraform. Great take.

Except it's not, because their example is trivially easy and common in Terraform.

The challenge isn't just defining multiple DNS records—it’s doing so dynamically based on an unknown number of instances at plan time. Terraform struggles with truly dynamic resource creation because it relies on a static graph. You can use count or for_each, but those require knowing the instances in advance within the Terraform configuration. If your instances are created dynamically outside Terraform (e.g., via auto-scaling groups), you hit limitations.

You can work around this by using external data sources or separate workflows (e.g., running Terraform after instances are created), but that just proves the point: Terraform isn’t fully "code" in the sense of having true loops and dynamic logic like a real programming language.

If you think this is trivially easy, show me how you'd do it without resorting to hacks like running terraform apply twice.

Re: Yoke: Infrastructure as code, but actually

#48

Earlier quoted context omitted.

Except it's not, because their example is trivially easy and common in Terraform.

The challenge isn't just defining multiple DNS records—it’s doing so dynamically based on an unknown number of instances at plan time. Terraform struggles with truly dynamic resource creation because it relies on a static graph. You can use count or for_each, but those require knowing the instances in advance within the Terraform configuration. If your instances are created dynamically outside Terraform (e.g., via au…

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 sequence that respects the dependency graph. Terragrunt makes this trivial.

Re: Yoke: Infrastructure as code, but actually

#49

Earlier quoted context omitted.

The challenge isn't just defining multiple DNS records—it’s doing so dynamically based on an unknown number of instances at plan time. Terraform struggles with truly dynamic resource creation because it relies on a static graph. You can use count or for_each, but those require knowing the instances in advance within the Terraform configuration. If your instances are created dynamically outside Terraform (e.g., via au…

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 multiple runs with external tools.

Yes, you can manage this with separate state files and a structured apply sequence (e.g., using Terragrunt), but that’s just adding more scaffolding to work around Terraform’s inability to express dynamic logic. That’s infrastructure orchestration, not infrastructure as code.

The fact that we have to rely on external tools or multi-step workflows to accomplish something that would be trivial in a real programming language just reinforces the point: Terraform isn’t really "code" in the traditional sense.

Post reply on HN