Hacker News Reader

Comment by SamuelAdams | Hacker News Reader

This seems to be less about K8’s and more about the infra as code movement. It doesn’t matter if you use K8, CDK, or terraform - you get the same benefits the OP stated across the board.

It is nice to be able to have a consistent deployment pattern, with traceability, rollback support, and production approval checks. It’s nice to not have some archaic something stuck in someone’s head. It’s also nice to be able to see how something works by reading the code, which is usually up to date and deployable.

View on HN

> less about K8’s and more about the infra as code movement. It doesn’t matter if you use K8, CDK, or terraform - you get the same benefits the OP stated

I’d like to gently push back on that. ;-D

Terraform, when committed to git, provides organisational memory. But less so uniformity, since all providers are different (and you should expect different things when applying). No tracing besides git. And tfstate is hard to share between developers, unlike kube state.

Kubernetes is more the same across providers. And it manages drift after something is applied, which is not a direct argument of OP, but a strong reason over other IAC.

And yes, I also enjoy how well deploying works. And how things generally fit together. Liking the networking complexity less so.

> And tfstate is hard to share between developers...

Really? For years and years we put our tfstate files into private S3 buckets at $DAYJOB and it seemed to work just fine. We didn't even take pains to ensure that everyone was on the very same version of the Terraform CLI. What problems did you guys run into?

One person upgrading terraform can break the state format for backwards compatibility. We use direnv with asdf to ensure everyone is in the same version now.

Run the apply via a pipeline. Pr merged in. Plan runs. Approval gate for apply.

Works on our staging and production environments, but the feedback loop is too long for development. I mean, if it was literally the only way then we’d live with it, but ensuring everyone is using the same version is enough.

IaC (capturing desired state declaratively) is a no-brainer for things like cloud resources IMO. Most use IaC for non-compute resources (e.x. DBs) and K8s for containerized compute workloads.

> But less so uniformity, since all providers are different

People sometimes misinterpret tools like Terraform supporting different vendors/hyperscalers as it providing a unified abstraction layer above them. As you note, it does not.

I simply fail to understand why automatic drift correction is considered important in this space. Cloud resources do not magically change themselves. Folks often cite rogue engineers making changes, but I prefer to deal with this scenario by whacking people with a stick and/or limiting access. Automatic drift correction can actually complicate making legitimate emergency changes to managed infrastructure.

Reply on news.ycombinator.com