Live data from Hacker News

Yoke: Infrastructure as code, but actually

xeiaso.net

151–160 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#151
post #65

Why is someone talking about infrastructure as code one moment, and then kubernetes manifests the next. The two are not the same. You can’t replace what Terraform or Pulumi does with kubernetes manifests.

You absolutely can. https://www.crossplane.io/ I'm managing a few dozen cloud accounts on azure and aws with nothing but crossplane and a very small terraform script that bootstraps the control plane account.

Ok, maybe you can, but I don’t think you should xD

It feels a bit like that MS Paint IDE that was posted a day ago.

Re: Yoke: Infrastructure as code, but actually

#152
what problem does it solve?

    - However, Pulumi has a few downsides:

    - You have to install the language runtimes and dependencies for the language you're using
    - The code has to run on the server that's managing the infrastructure
 
    This sounds reasonable at first, but then you come to the shocking realization that code that runs on the host machine can do literally anything it wants. This means that if a dependency gets popped, your infrastructure is now compromised and likely has cryptocurrency miners running on it.
can't you just put whatever you use to manage infrastructure in a docker container / appimage / whatever and be free of "what if dependencies contain cryptominers" problem?

Re: Yoke: Infrastructure as code, but actually

#153

Earlier quoted context omitted.

Yep, and that's why I only very recently picked it up in Enterprise world, where the AWS team used it to deploy resources. What used to take them ~45min by hand using prebuilt AMIs, now takes ~500 lines of Terraform "code" and several hours of troubleshooting every time Terraform (or whatever fork they're now using post-Hashicorp) updates/changes, because Enterprise architecture is mutable by default and cannot simpl…

>What used to take them ~45min by hand using prebuilt AMIs, now takes ~500 lines of Terraform "code" and several hours of troubleshooting every time This is just operational immaturity. No one should be building anything "by hand," everything should be automated. Deploying instances from prebuilt AMIs takes a dozen or so lines of Terraform code. Terraform can spin up dozens of instances in less than 5 minutes with a…

> Enterprise architecture is immutable by default now, and destroying and replacing is the norm.

real life is harder. If I have a cluster of 8 H200 machines running training I can't really destroy it and redeploy. Technically I can but I need to spend time with the data scientists to make sure they configured everything to continue training from checkpoints. And if this cluster is idle for a day the amount of money wasted is around my monthly salary..

hm, maybe more enterprisey clusters are used in a such a way that any node can be replaced at any time.

Re: Yoke: Infrastructure as code, but actually

#154
post #99

Earlier quoted context omitted.

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

You don’t need any of that. Define a data source to query the instances and then a for_each DNS resource using the data source instances.

Re: Yoke: Infrastructure as code, but actually

#155

Earlier quoted context omitted.

Yep, and that's why I only very recently picked it up in Enterprise world, where the AWS team used it to deploy resources. What used to take them ~45min by hand using prebuilt AMIs, now takes ~500 lines of Terraform "code" and several hours of troubleshooting every time Terraform (or whatever fork they're now using post-Hashicorp) updates/changes, because Enterprise architecture is mutable by default and cannot simpl…

>What used to take them ~45min by hand using prebuilt AMIs, now takes ~500 lines of Terraform "code" and several hours of troubleshooting every time This is just operational immaturity. No one should be building anything "by hand," everything should be automated. Deploying instances from prebuilt AMIs takes a dozen or so lines of Terraform code. Terraform can spin up dozens of instances in less than 5 minutes with a…

> Deploying instances from prebuilt AMIs takes a dozen or so lines of Terraform code. Terraform can spin up dozens of instances in less than 5 minutes with a dozen lines of code

That's ignoring everything that goes into even deciding the "nitty-gritty" around the deployment, which is where the bulk of the code comes from. What security keys does the customer use? Do we use ASGs or one-offs? Is the underlying application fault tolerant or not? Does the customer require backups? What subnet does it go in? What security groups need to be added? What are the tags? Is it region-specific? Does it belong in a higher security zone? Does it need specific failover criteria?

500 lines later, you can deploy one VM with everything needed to meet the customer and organizational demands. That's not efficient, but that's how enterprise technology ultimately works.

> Maybe for laggards it's true, but modern enterprises with modern ops teams using modern tooling are deploying most of everything with immutability in mind. Enterprise architecture is immutable by default now, and destroying and replacing is the norm.

So throwing insults isn't exactly helping here, because I'm literally coming from said modern ops teams, using said modern tooling, from a large enterprise. You can apply a universal standard to "all enterprise" all you want, but the cruel reality is that most Enterprise technology does not work in the way you are describing. ERP servers remain mutable, database clusters are mutable, Physical Security appliances are mutable, hypervisor ops appliances are mutable, VPN concentrators are - you guessed it - mutable. We have built the tooling to support immutable architecture, we have demonstrated its capabilities to the Enterprise, we are ready for Kubernetes and Containers both on-prem and in the cloud, but our customers and applications flatly do not use or support it.

This is something I have had to explain time and again to the Powers that Be (TM), that Enterprise Technology and Product Technology needs/pipelines/customers are vastly different, with different paces, needs, and operational goals. No amount of Terraform, Ansible, GitHub Actions, Argo Workflows, Puppet, or other pipeline add-ons are going to speed up Enterprise Technology, because the software providers do not care to do so. If your Enterprise application selection enables immutable architecture across the board, you are exceedingly lucky to have leaders who allow that to be the case, because in my experience - from small MSPs, to major publishers, to giant tech conglomerates, and everywhere in between - Enterprise Technology is mostly mutable infrastructure with old-but-custom software that will never, ever be modernized, and often with SLAs far superior than anything public customers are allowed to have.

Re: Yoke: Infrastructure as code, but actually

#156

Earlier quoted context omitted.

>What used to take them ~45min by hand using prebuilt AMIs, now takes ~500 lines of Terraform "code" and several hours of troubleshooting every time This is just operational immaturity. No one should be building anything "by hand," everything should be automated. Deploying instances from prebuilt AMIs takes a dozen or so lines of Terraform code. Terraform can spin up dozens of instances in less than 5 minutes with a…

> Enterprise architecture is immutable by default now, and destroying and replacing is the norm. real life is harder. If I have a cluster of 8 H200 machines running training I can't really destroy it and redeploy. Technically I can but I need to spend time with the data scientists to make sure they configured everything to continue training from checkpoints. And if this cluster is idle for a day the amount of money w…

And this gets into another complication of ET that doesn't happen with PT: with Product Tech, the onus is on the customers to modernize around a new update, whereas with ET, it's our responsibility to work around the customers, on their schedule, and their timeline, unless we want to be fired for "bad customer service".

We cannot simply rip and tear like Product can, placing trust in your orchestrators to rebuild from configs with brand new instances. We can't spool up Chaos Monkey and test-tank the ERP system, because the ERP team has no interest (or political benefit) in modernizing their infrastructure to support Configuration Management tools or pipelines.

Re: Yoke: Infrastructure as code, but actually

#157

Earlier quoted context omitted.

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

You don’t need any of that. Define a data source to query the instances and then a for_each DNS resource using the data source instances.

If your instances are created by Terraform itself, sure, you can use for_each with a data source to define DNS records dynamically. But if the instances are created dynamically outside of Terraform—such as through an auto-scaling group—then Terraform's static plan model becomes a problem.

Terraform data sources can read existing infrastructure, but they don't automatically trigger new resource creation based on real-time changes. That means your DNS records won't update unless you manually run terraform apply again, and they won’t be part of a single apply cycle. In contrast, a real programming language could handle this as a continuous process, responding to infrastructure changes in real-time.

So yes, you can query instances with a data source and use for_each—but unless you’re running Terraform repeatedly to catch changes, your DNS records won’t reflect real-time scaling events. That’s the exact limitation I’m talking about: Terraform isn’t imperative, it’s declarative, and it doesn’t react dynamically at runtime without external orchestration.

Re: Yoke: Infrastructure as code, but actually

#158
post #68

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…

> code should be optimised to be easy to READ You say that as if it’s impossible to write clear code. As soon as you have any form of multiple resources (e.g. create x of y) I’ll take the real programming language over terraform.

Fortunately, Terraform has CDKTF [1] which allows you to use common languages such as Python, Java, and TypeScript to author Terraform infra.

I used it daily and find it greatly liberating.

[1] https://developer.hashicorp.com/terraform/cdktf

Re: Yoke: Infrastructure as code, but actually

#159
post #75

From the website: > New tools like CUE, jsonnette, PKL, and others have emerged to address some of the short comings of raw YAML configuration and templating. Inspiring new K8s package managers such as timoni. However it is yoke’s stance that these tools will always fall short of the safety, flexibility and power of building your packages from code. The never-ending debate continues between configuration languages an…

It will once traditional languages are good enough

Traditional languages will not remove the features that make them poor for configuration.

I can’t imagine Python dropping the ability to query the current date, for example.

Re: Yoke: Infrastructure as code, but actually

#160

Earlier quoted context omitted.

Not OP, but for rolling back we just… revert the change to the setup_k8s_stuff.py script ! In practice it’s a module that integrates with quite a large number of things in the monolith because that’s one of the advantages of Infrastructure as Actual Code : symbols and enums and functions that have meaningful semantics in your business logic are frequently useful in your infrastructure logic too. The Apples API runs o…

> revert the change to the setup_k8s_stuff.py script What about resources that were created by the code you reverted?

it's not fair to ask such questions
Post reply on HN