> The IaC ecosystem is not the Javascript ecosystem; If you use good modules, pin them to a specific version, and update when you need to then you won’t run into the dependency issues that you may have elsewhere.
That’s a half-truth. The IaC consulting I take part of is overwhelmed equally by npm and docker/helm dependency hell.
Sure, worms in npm. But just as many things breaking and getting deprecated in IaC land. Bitnami deprecating their charts. Zookeeper operator breaking on newer Linux kernels. Lagoon not respecting resource requests.
“But if you stick to the good packages!” works for any package ecosystem. It’s just that sometimes you don’t choose the packages.
My only counter-argument: sometimes it is cheaper to maintain your own fork of something. Sometimes it is cheaper to make your own thing.
Gowiem•3mo ago
That's a reasonable take! Yes, there are tradeoffs and there are bad OSS actors (like Bitnami) that make it hard to state anything in this realm as a hard truth.
In this article, I'm fairly focused on the Terraform + OpenTofu IaC child module ecosystem in which I'm not aware of anyone who has done that sort of rug pull. I get your point though and that is why I included the "How you should evaluate good OSS" steps towards the end of the article. Hopefully that helps folks pick good packages...
sshine•3mo ago
In Terraform/OpenTofu you just run into unreliable providers, 3rd party providers that make your supply chain a little questionable, or providers with half-broken APIs that weren’t ever intended to be called via terraform. (How many hashpin their binary third party providers? https://github.com/nix-community/nixpkgs-terraform-providers... is still open after 2 years.)
Not just bad FOSS actors, things just fall apart in every ecosystem over time as actors stop contributing.
More dependencies = more problems. Long dependency chains means more dependencies. IaC generally doesn’t have long chains. But you can still depend on a ton of dockerfiles, images, charts, and the same software that gets packaged ends up with CVEs in images rather than at the library import level.
cassianoleal•3mo ago
If your infra isn't special, then you shouldn't require third-party modules. Knowing how to compose resources in a Terraform module is table stakes, and if you don't know what resources are involved and how they're configured, you're going to have a hard time troubleshooting things or extending them when your infra finally becomes special enough.
OTOH, if your infra is indeed special, then third-party modules become a hindrance. They add complexity for no clear gain.
sshine•3mo ago
That’s a half-truth. The IaC consulting I take part of is overwhelmed equally by npm and docker/helm dependency hell.
Sure, worms in npm. But just as many things breaking and getting deprecated in IaC land. Bitnami deprecating their charts. Zookeeper operator breaking on newer Linux kernels. Lagoon not respecting resource requests.
“But if you stick to the good packages!” works for any package ecosystem. It’s just that sometimes you don’t choose the packages.
My only counter-argument: sometimes it is cheaper to maintain your own fork of something. Sometimes it is cheaper to make your own thing.
Gowiem•3mo ago
In this article, I'm fairly focused on the Terraform + OpenTofu IaC child module ecosystem in which I'm not aware of anyone who has done that sort of rug pull. I get your point though and that is why I included the "How you should evaluate good OSS" steps towards the end of the article. Hopefully that helps folks pick good packages...
sshine•3mo ago
Not just bad FOSS actors, things just fall apart in every ecosystem over time as actors stop contributing.
More dependencies = more problems. Long dependency chains means more dependencies. IaC generally doesn’t have long chains. But you can still depend on a ton of dockerfiles, images, charts, and the same software that gets packaged ends up with CVEs in images rather than at the library import level.