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

31–40 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#31

Post by danw1979 »

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 to that platform team and have to manage the state of tens of thousands of "pet" resources that you can't just nuke and recreate using the CDK (because some other team depends on their avaiability) then Terraform is the best thing since sliced bread; it manages state, drift, and the declarative nature of the DSL is desirable.

Horses for courses.

Re: Yoke: Infrastructure as code, but actually

#32

Post by thayne »

> This is not code. This is configuration.

I don't think those two things are mutually exclusive.

IMO hcl is absolutely code. As is html, and css, json, and yaml.

It isn't a full programming language, and I often wish it was, but I wouldn't say it isn't code.

Re: Yoke: Infrastructure as code, but actually

#33

Post by danw1979 »

smithcoin wrote: post #27

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 what you think is deployed

2. Import all your resources into the state file

3. Run a `terraform plan ...` to show what Terraform wants to change about your resources (including creating any you missed or changing/recreating any your config doesn't match)

4. Correct your TF configuration to reflect the differences from 3.

5. Goto 3, repeat until you get a "No changes" plan or the you actually want TF to correct some things (add tags, for example)

6. run `terraform apply`

and optionally...

7. set up your CI/automation to run `terraform plan` regularly and report the "drift" via some means - stuff that has been changed about your resources outside of Terraform management.

I put a lot of stock in this last step, because small, incremental change is the cornerstone of platform management. If you want to make a change and come to find there's a huge amount of other stuff you have to correct as well, your change isn't small any more.

Re: Yoke: Infrastructure as code, but actually

#34

Post by jiggawatts »

solatic wrote: post #19
gorgoiler wrote: post #10

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…

> I imagine reverting changes in a mutable environment is indeed quite hard to get right (and what you are hinting at?) I guess you're not managing any databases then? Because you can't just treat those immutably, you have to manage the database in-place.

One thing that annoys me is the inconsistency between mutable "data" resources and everything else.

Something that would be nice would be the rough equivalent of the deployment slots used in Azure App Service, but for everything else too. So you could provision a "whole new resource" and then atomically switch traffic over to it.

Re: Yoke: Infrastructure as code, but actually

#35

Post by Stranger43 »

iliec wrote: post #13

This seems like a great approach that sits between using the sdk directly and a dsl/yaml. My experience has been that most of the people configuring these systems don’t know how to code, and configuration languages is their gateway. Most never venture past configuration which is why yaml is so used and difficult to get any traction outside of it. I think terraform adopted some of the patterns which have been around s…

But doesn't the codeless "infrastructure as code" kind of smell like cargo cult practices, i mean there might be places where having your infrastructure defined as data is a really good thing, but at least in my work i keep hitting roadblocks where i really wish i was writing actual logic in a modern scripting language rather then trying to make data look like code and code look like data, which is what a lot of devops tutorials seem to be teaching.

Re: Yoke: Infrastructure as code, but actually

#36

Post by politelemon »

xena wrote: post #24
skinkestek wrote: post #23

Earlier quoted context omitted.

Ahh, good point. I guess Rust (and maybe other unmanaged languages) can be compiled to WebAssembly?

Yes: Go: https://go.dev/blog/wasi Rust: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

.net: https://devblogs.microsoft.com/dotnet/extending-web-assembly...

Re: Yoke: Infrastructure as code, but actually

#37

Post by bbu »

xena wrote: post #9
bbu wrote: post #7

Looks 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.

ok, that makes sense. A better Helm would be nice. timoni.sh is getting better and better, but Cue is a big hurdle.

Unfortunately, I'm not a big fan of the yaml-hell that crossplane is either.

But as a Terraform replacement systeminit.com is still the strongest looking contender.

Re: Yoke: Infrastructure as code, but actually

#38

Post by solatic »

jiggawatts wrote: post #34
solatic wrote: post #19

Earlier quoted context omitted.

> I imagine reverting changes in a mutable environment is indeed quite hard to get right (and what you are hinting at?) I guess you're not managing any databases then? Because you can't just treat those immutably, you have to manage the database in-place.

One thing that annoys me is the inconsistency between mutable "data" resources and everything else. Something that would be nice would be the rough equivalent of the deployment slots used in Azure App Service, but for everything else too. So you could provision a "whole new resource" and then atomically switch traffic over to it.

You can express this in Terraform, it's just a little more contrived. You release your changes as Terraform modules (a module in and of itself doesn't do anything, it's like a library/package), then your Terraform workspace instantiates both a "blue" module and a "green" module, at different versions, with DNS / load balancing resources depending on both modules and switching between either blue or green.

Re: Yoke: Infrastructure as code, but actually

#40

Post by grahar64 »

I was 100% for infra as code as it gives devs more freedom to get what they need. Then the startup went from 50 to 100 to 1000 and people just needed to get stuff done and usually the exact same thing over and over. So we migrated to a custom DSL which is much easier to standardize, lint, review and read. I think when you don't know what you need code is better for flexibility, when the domain is sorted, DSL.
Post reply on HN