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

81–90 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#81

Post by postpawl »

INTPenis wrote: post #80
postpawl wrote: post #79

Earlier quoted context omitted.

A lot of important devops tools like Kubernetes and Grafana are written in golang, and it’s often handy to be able to import their code to use in your own code to automate those things.

But again, you're now a developer. And I'm asking who are these developers using IaC tooling? It seems to me like it was made for ops. All power to you if you take on both roles, but that's a good way to get burned out. I'm a devops person so the devs can focus on just code, and I can focus on making the best and safest infrastructure for them to run their code in.

Those developers are working on “Internal Development Platforms” and building their own abstractions on top of tools like Kubernetes and Grafana to simplify things for developers. This page explains it pretty well: https://internaldeveloperplatform.org/what-is-an-internal-de...

Re: Yoke: Infrastructure as code, but actually

#83

Post by bionhoward »

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…

A big benefit is the compiler catches bugs so you don’t have to wait around for your Python program to crash at runtime. Also, if the type system is more “legit” then you can skip a ton of defensive parsing of inputs.

Could be more about developers who know Golang and Rust wanting to deploy their apps (no need to pigeonhole anyone into just dev or just ops)

Re: Yoke: Infrastructure as code, but actually

#84

Post by klooney »

solatic wrote: post #15

> 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 depends on where the source of dynamism is coming from, but yes you can do this in Terraform. You get the instances with data.aws_instances, feed it into aws_route53_record with a for_e…

https://registry.terraform.io/providers/hashicorp/random/lat... is also very useful for this sort of thing, in case you want a persistent random value per resource- shuffle, id, pet, and password are all super handy.

Re: Yoke: Infrastructure as code, but actually

#85

Post by ForTheKidz »

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 don't really see a distinction between developer and ops person in this context. The whole point of all of these tools is to make infrastructure into code. Go isn't the choice I would have made but it's fine.

Re: Yoke: Infrastructure as code, but actually

#86

Post by klooney »

kikimora wrote: post #43
voidfunc wrote: post #4

I 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’ve been thinking about this for a long time. But doesn’t it brings a host of other issues? For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created? I need to make a small change, how do I know what parts of my scripts to run?

Here are the things that TF does that you are probably not going to get around to in a comprehensive way-

- State tracking, especially all of the tedious per cloud resource details

- Parallelism- TF defaults to 10 threads at a time. You won't notice this when you write a demo to deploy one thing, but it really matters as you accrete more things.

- Dependency tracking- hand in hand with the parallelism, but this is what makes it possible. It is tedious, resource by resource blood sweat and tears stuff, and enabled by the inexpressive nature of HCL

Plus, you know, all of the work that has already done by other people to wrap a million quirky APIs in a uniform way.

Re: Yoke: Infrastructure as code, but actually

#87

Post by patrick451 »

akdor1154 wrote: post #58

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…

>whoever comes across your clever code next will probably want to hit you, especially if it's not a dev from your immediate team, and especially if you have succumbed to blurring the lines between your idk code and your app code.

If you want to maximize the number of people who have a chance of understanding what is happening, python is your huckleberry. They are going to want to hit the guy who wrote everything in a bizarre language called HCL that nobody outside of infra has ever seen or heard of.

> If they instead come across some bog-standard terraform that maybe has a bunch of copy-paste and is a bit more verbose... Who cares? Its function will be obvious, there is no mental overhead needed.

"bog standard" is doing a lot of heavy lifting here. You can write simple python or esoteric python and you can write simple terraform or esoteric terraform.

Re: Yoke: Infrastructure as code, but actually

#88

Post by terrabitz »

INTPenis wrote: post #80
postpawl wrote: post #79

Earlier quoted context omitted.

A lot of important devops tools like Kubernetes and Grafana are written in golang, and it’s often handy to be able to import their code to use in your own code to automate those things.

But again, you're now a developer. And I'm asking who are these developers using IaC tooling? It seems to me like it was made for ops. All power to you if you take on both roles, but that's a good way to get burned out. I'm a devops person so the devs can focus on just code, and I can focus on making the best and safest infrastructure for them to run their code in.

I feel like the distinction between the two is fairly contrived these days. I'm an SRE, and we're constantly building tooling to help us better manage infrastructure, improve reliability, improve DX, etc. On the flip side, we also push a lot of the responsibility for infrastructure management to our devs: we maintain the modules and IaC pipelines, and the developers hook up the building blocks they need. It can actually help avoid burnout because our team doesn't become a bottleneck for infrastructure provisioning.

Say what you want about IaC in Go or other programming languages, but it can definitely help strengthen the whole "developers own their infrastructure" since they don't have to learn an additional language syntax.

Re: Yoke: Infrastructure as code, but actually

#89

Post by ljm »

solatic wrote: post #15

> 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 depends on where the source of dynamism is coming from, but yes you can do this in Terraform. You get the instances with data.aws_instances, feed it into aws_route53_record with a for_e…

K8S is at a point now where I'd probably try to configure whatever I can inside the cluster as an operator or controller.

There are going to be situations where that isn't practical, but the ability to describe all the pieces of your infra as a CRD is quite nice and it takes some pain out of having things split between terraform/pulumi/cdk and yaml.

At that point, you're just running your own little cloud instead of piggybacking on someone else's. Just need a dry-run pipeline so you can review changes before applying them to the cluster.

Re: Yoke: Infrastructure as code, but actually

#90

Post by solatic »

ljm wrote: post #89
solatic wrote: post #15

> 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 depends on where the source of dynamism is coming from, but yes you can do this in Terraform. You get the instances with data.aws_instances, feed it into aws_route53_record with a for_e…

K8S is at a point now where I'd probably try to configure whatever I can inside the cluster as an operator or controller. There are going to be situations where that isn't practical, but the ability to describe all the pieces of your infra as a CRD is quite nice and it takes some pain out of having things split between terraform/pulumi/cdk and yaml. At that point, you're just running your own little cloud instead of…

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