I went into this article kind of expecting something cool and neat, and it is… but it appears to be only k8s?

Maybe open with a k8s example instead of a route53 + vultr example? Or provide how to replicate that with yoke?

The whole field is plagged with people with poor understanding of computing resulting into some rather bizarre oddities:

• “As code” is a miss. What they mean is a declarative definition acting as single source of true. Mind you you, many of these solutions fail at being declarative leading to a constant chase of the best tool. Because they don’t understand the fundamental problem at had.
• At its fundamental level, the problem requires a way (any) to define data structures. And possibly some programable way of re-using values or derive a value from another one. This could be left to an external tool, such as a programming language or a template language. Jamming a new programming language with its own parser and interpreter into it, is like buying a car because you like to sit on its sits. Sure, the sits are usable, but they make these things called sofas.

As I write this, I imagine lisp programmers thinking: “like we have been doing for half a century?”.

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-demo.ysh

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/output.txt

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_for_unix

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.

Running Pulumi inside a VM on your laptop/server would create a similar level of isolation as using the WebAssembly sandbox in Yoke, if an attacker gains sufficient access to your server, they could potentially compromise both a WebAssembly sandbox and a VM depending on the depth of access and vulnerabilities exploited

@cadey

I am not a big fan of terraform, but I’ve been full time terraform engineering for the past week.

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.

I believe this is possible using a data … “instances” { filter { … } } to select the instances, and then a resource … { each = data….instances } or a module … { each = data…instances } to create the per instance resources. But I’m not really sure based on the description what you mean by “dynamic”.

The instance count could also be an input to a module (?). If the module is creating the instances based off an input count, then you make the instances using an each, and then directly pass around the instance list result from that instead of using a data+filter block.

If you need controlled randomness, the “random” provider can give you random bytes or a random ID that only changes when some input “keepers” change. I use this to generate a ConfigMap name suffix that changes when the config stored in the ConfigMap changes.

I’m actually working on the exact same thing right now and hadn’t heard of Yoke. Are there any other tools in this space with the same approach? The space being the layer where the objects are distributed systems primitives, which I think is a sweet spot for easing some of the pain of modern devops.

Calling something “not code” because it’s not as flexible as some other languages seems unnecessarily gatekeepy.

Yoke does seem interesting and I’ll look into it more.

This is a great writeup, and in the nick of time for a new thing I’m prototyping at work. As a developer with minimal dev ops experience, I would love to use Go to manage my infra.

I wonder if it works well with renovate or largo to keep images updated.

Yoke does seem to be really cool, and for me it’s worth giving a close look. I believe that I have been in a similar space for a few years right now, looking for an optimal solution for Kubernetes configuration management. Up to this point this has been Kustomize along with KRM functions. There is also kpt, but I have not yet had the time to try it out. I was drawn into this article hoping to see a comparison with KRM functions, as it seems conceptually very similar.

I have been mostly satisfied with kustomize and KRM functions, with a few caveats. I wont mention them all here, but the main thing that irks me right now is that with my chosen solution with ArgoCD I end up using KRM exec functions bundled within an ArgoCD CMP plugin. This means – among other things – that if a user wanted to render the manifests locally on their own workstation that they would need to imitate the ArgoCD CMP environment to render the same manifests instead of running the containerized KRM functions in separate containers as they were intended.

I see that yoke also requires a CMP plugin to integrate with ArgoCD, which isn’t really a problem in itself. If yoke ends up being a game changer hopefully ArgoCD will support it as a native plugin.