Yoke: Infrastructure as code, but actually
1–10 of 169 posts
Re: Yoke: Infrastructure as code, but actually
#2If 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.
Re: Yoke: Infrastructure as code, but actually
#3> 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.
It's possible a few ways. I prefer modules, and this LLM answer describes an older way with count and for_each.
It's always possible that incantation of the problem space has a gotcha that needs a work around, but I doubt it would be a blocker.
https://www.perplexity.ai/search/if-you-really-do-think-that...
Re: Yoke: Infrastructure as code, but actually
#4I 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.
Re: Yoke: Infrastructure as code, but actually
#5I 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.
How are you handling creating multiple resources in parallel? or rolling back changes after an unsuccessful run?
Re: Yoke: Infrastructure as code, but actually
#6I 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 agree that the SDK is better for many use cases. I do like terraform for static resources like aws vpc, networking, s3 buckets, etc.
Re: Yoke: Infrastructure as code, but actually
#7Looks promising but it starts with a (justified) rant about terraform and then goes into how to replace Helm.
I am confused. Can yoke be used to create and manage infrastructure or just k8s resources?
Re: Yoke: Infrastructure as code, but actually
#8From 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 and traditional languages. I don't know if the industry will ever standardize in this area.
Re: Yoke: Infrastructure as code, but actually
#9Looks promising but it starts with a (justified) rant about terraform and then goes into how to replace Helm. I am confused. Can yoke be used to create and manage infrastructure or just k8s resources?
Author here. It's mainly for k8s resources; but if you install operators like external-dns or something like crossplane into your cluster, you can manage infra too.
Re: Yoke: Infrastructure as code, but actually
#10I 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.
How are you handling creating multiple resources in parallel? or rolling back changes after an unsuccessful run?
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 on the Apples tier, the Oranges API runs on the Oranges tier, etc. etc.
People call me old fashioned (“it’s not the 1990s any more”) but when I deploy something it’s a brand new set of instances to which traffic gets migrated. We don’t modify in place with anything clever and I imagine reverting changes in a mutable environment is indeed quite hard to get right (and what you are hinting at?)