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