Yoke: Infrastructure as code, but actually

Here is a thing I run into a lot:

"Our infra is brittle and becoming a chore to manage, and is becoming a huge risk. We need IAC!" (At this point, I don't think it's a bad idea to reach for this)

But then -

"We need to manage all our IAC practices like dev ones, because this is code, so we will use software engineering practices!"

Now I don't entirely disagree with the above statement, but I have caveats. I try to treat my IAC like "software" as much as I can, but as you pointed out, this can break down. Example: managing large terraform repositories that touch tons of things across an organization can become a real pain with managing state + automation + normal CI/CD practices. I can push a terraform PR, get approved, but I won't actually know whether what I did was valid until you try to push it live. As opposed to software, where you can be reasonably confident that the code is going to mostly work how you intend before you deploy it. Often in infra, the only way to know is to try/apply it. Rollback procedures are entirely different, etc.

It also breaks down as others have noted trying to use terraform to manage dynamic resources that aren't supposed to be immutable (like Kubernetes). I still do it, but it's loaded with foot guns I wouldn't recommend to someone that hasn't spent years doing this kind of thing.

Or (god forbid) a proper runtime like just the OS and architecture of the platform you're running the tool on.

This article calling out Go because you have to prebuild binaries for every OS and architecture combination beforehand (even though you probably already know this combination and it's likely small) and saying that doesn't scale but then requiring every user to not just get the WASM binary they want to run but _also_ just get the (OS and architecture-specific) runtime for the environment seems unfair.

Anything where you distribute your application in a way that isn't immediately usable on a target platform without having to set up an environment of some kind feels like a 'Shift right deployment' kind of thinking, where it's fine to do the bare minimum to make your tool available and it's now an end user's problem to get everything set up to run it.

In some cases this is fine and the cost is low (same-language library usage for example) but when it comes to tool distribution every time I see 'cargo install' for someone's cute Rust project or an instruction to 'just do the following ten steps and you can run the executable' I usually just back away from GitHub and don't bother.

Applying changes in a structured, staged approach via that separation is a great way to avoid issues that will be obfuscated when managing infrastructure in other ways.

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 dozen lines of code: https://dev.to/bennyfmo_237/deploying-basic-infrastructure-o...

If you're not operationally mature enough, the problem isn't the tool, it's you. This is basic Terraform usage.

>because Enterprise architecture is mutable by default and cannot simply be torn down and replaced.

This is no longer correct/true. 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.

I’ll be the first to agree that CDK sucks, but Pulumi is essentially Terraform as a programming language, with all the niceties of terraform and more besides.

The format that defines what infra looks like is… very hard to parse with terraform (for me). It seems optimized for defining a list of static resources, and everything else is bolted on. The for_each or count constructs do not make intuitive sense to me anyway.

That said, by all means, use Terraform, as long as it’s not CDK I’ll be happy.