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

111–120 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#111

Post by Kinrany »

empath75 wrote: post #91
INTPenis wrote: post #76

Who are these ops people that want to write golang and rust? It seems like a tiny niche. If you're that comfortable writing golang or rust then why not just become a developer? I'm a lifelong ops person, since 2000, and I use Ansible or Terraform daily. I often wanted to learn golang better but I just never had the motivation. I'm a mean Python scripter, I can write a system integration in hours, but there's somethin…

I've written a bunch of k8s operators in go (and rust more recently). That's how basically everyone working with k8s does once you reach a certain level of complexity. I don't really understand, in fact, why you'd use yoke instead of just writing an operator with kubebuilder or kube-rs.

Supposedly it's a package manager as well, so if there's a package, you'd be able to use it without writing any code.

Re: Yoke: Infrastructure as code, but actually

#112

Post by figmert »

Slightly related, in everything I see that allows adding secrets or env vars as code, they seem to prefer a list of objects instead of a key value pair for these. Does anyone know why this is? I know in some cases you can add additional values, but this seems easily solved by dynamically determining what the value is.

I'd much rather write:

    env:
      key: value
instead of

    env:
      - name: key
        value: value

Re: Yoke: Infrastructure as code, but actually

#113

Post by evantbyrne »

dijksterhuis wrote: post #102
evantbyrne wrote: post #96

Earlier quoted context omitted.

I went through the same evolution, even built a PaaS for AWS, but I kept going and now just deploy my own stuff to VMs with Swarm via one command in Rove. It's great. And yes I know kubernetes I use it at work. It's an unnecessary waste of time.

> Swarm docker swarm is so simple and easy compared to the utter behemoth that is k8s, and basically is all you need for CRUD webapps 80-90% of the time. add an RDS instance and you’re set. i will always pick swarm in a small company* whenever possible until k8s or ECS makes sense because something has changed and it’s needed. dont start with complexity. * - bigger companies have different needs.

People have really been sleeping on Swarm. I sometimes even see people trying to recreate Swarm features with Compose. Wish more devs knew about it.

Re: Yoke: Infrastructure as code, but actually

#114

Post by kacesensitive »

tekla wrote: post #99
kacesensitive wrote: post #55

Earlier quoted context omitted.

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

Yes, if you use your tools poorly, it will turn out badly. I run infra that has dynamic scaling provisioned via Terraform. Guess what, we auto-scale from hundreds to thousands of boxes a day dynamically managed through TF and we have had no issues, since we bothered to figure out how to do it properly.

I don’t doubt that you’ve made Terraform work for your needs. The point isn't that Terraform can't be used for dynamic infrastructure—it's that doing so requires workarounds like pre-split state files, sequential applies, or additional tooling like Terragrunt. That’s not the same as having a truly dynamic system where resources can be created and modified in response to real-time conditions without external orchestration.

Terraform works well for many cases, but the fact that you had to “figure out how to do it properly” kind of proves the point—it’s not inherently designed for dynamically changing infrastructure within a single apply cycle. If it were, you wouldn’t need external coordination to handle something as simple as "create DNS records for all instances, even if the number changes at runtime."

At the end of the day, Terraform is great for declaring infrastructure, but it lacks the flexibility of programming infrastructure. If you’re happy with the trade-offs, great—but let’s not pretend those trade-offs don’t exist.

Re: Yoke: Infrastructure as code, but actually

#115

Post by Kinrany »

bbkane wrote: post #101
Kinrany wrote: post #75

Earlier quoted context omitted.

It will once traditional languages are good enough

I disagree - I think there are fundamental tradeoffs between declarative and imperative ways of configuration so they'll never "converge" completely. I am a huge fan of each camp stealing ideas from the other and thus "converging" closer. I also like the two-step "write imperative code to generate declarative config" approach some systems take - Terraform/Pilumi do this. At the cost of having two steps, you get to wr…

Configuration languages are just structured data, and programming languages also need to be able to express complex literal data.

JSON is already explicitly designed as a ~subset of JavaScript. An equivalent of a JSON written as a JavaScript literal is easier to read than JSON. The only problem is that we often don't want to use an interpreter to parse data.

Re: Yoke: Infrastructure as code, but actually

#116

Post by jon-wood »

> Yoke is a project that takes this basic idea to the next level. With Yoke, you write your infrastructure definitions in Go or Rust, compile it to WebAssembly, and then you take input and output Kubernetes manifests that get applied to the cluster.

This just puts me in mind of https://howfuckedismydatabase.com/nosql/

Re: Yoke: Infrastructure as code, but actually

#117

Post by [deleted] »

figmert wrote: post #112

Slightly related, in everything I see that allows adding secrets or env vars as code, they seem to prefer a list of objects instead of a key value pair for these. Does anyone know why this is? I know in some cases you can add additional values, but this seems easily solved by dynamically determining what the value is. I'd much rather write: env: key: value instead of env: - name: key value: value

[deleted]

Re: Yoke: Infrastructure as code, but actually

#118

Post by dionian »

SOLAR_FIELDS wrote: post #110
solatic wrote: post #90

Earlier quoted context omitted.

Sure, but the Kubernetes cluster itself, plus its foundational extra controllers (e.g. FluxCD) are basically static and therefore should be configured in Terraform.

That’s only true if you go with an architecture that involves doing so in terraform. A common pattern I implement is an initial management cluster bootstrap that runs Argo then after that it’s possible to manage everything, including cluster components of “child” clusters, using Argo. Can use either cluster api provider or cross plane for that, or one of the cloud specific ones like ack. One single imperative helm in…

This is similar to what I do. Terraform for anything that can't be in K8s. Create EKS cluster and bootstrap it with Argo. Then everything else is blissfully not in Terraform.

Re: Yoke: Infrastructure as code, but actually

#120

Post by weakfish »

We use Pulumi at my org, with TypeScript, and it’s actually genuinely a great experience to be able to have typed outputs of infrastructure.

Example, poorly explained as I’m on mobile:

- create an S3 bucket object - assign bucket.name to a variable - use variable as input to the creation of the managed airflow object, which asks for an S3 bucket as part of it’s config

Post reply on HN