It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame.
I did try Pulumi a while back, but the compatibility with Terraform modules was not great, so I've switched to CDKTF, which can handle unmodified modules. Dunno if I'll switch back to Pulumi or just use OpenTofu directly.
> It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame.
All their branding does this now, including the HashiCorp logo on their website [0]. There's gotta be a name for this specific branding pattern, but I don't know it.
I was recently working for a company which got acquired by IBM and we had to do it too. It’s an IBM thing. I bet most people at HashiCorp hate it, at least that was the case for us.
You can just switch from `count = 1` to `enabled = true` (or vice-versa, works back-and-forth) for a resource and tofu will automatically move it next time you apply.
I’m not sure I understand. You refer to the conditional resource fields normally - without list indices. You just have to make sure the object isn’t null.
There’s some samples in the docs[0] on safe access patterns!
Now more will be using a combination of OpenTofu and Terraform, and there will probably be some tacit endorsement of OpenTofu by Hashicorp folks in their communication with those who are using both. Good to see!
> It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame.
Or it's legal trying to preempt a risk.
If it was the author just wanting to point at IBM, they'd mention it just once or twice, but using that awkward phrase throughout the text makes me think it was an edit mandated by a careful lawyer.
Being able to inherit from Ingress and add a parameter of say public=True/False and then it change annotations, middleware, etc and then being able to re-use that across 100s of stacks is very powerful. DRY is not something HCL is good at.
Getting too clever with an imperative language in what is inherently a declarative domain, is an idea bad enough that they invented a whole new language to avoid you doing it. But some lessons have to be learned the hard way I guess
If you have the expertise and restraint to not go off the rails, I agree, imperative is more powerful. That plan does not survive teams of sizes over 2 in the majority of cases.
Exactly. It's just so much cleaner to do it in the Cloud provider's native tooling. The impedance mismatch from Cloud-agnostic abstractions always just makes thing shitty enough that in the long run you spend more time dealing with weird edge cases.
Besides, actual full-scale Cloud migrations are exceedingly rare.
I always hated this meme. Using Terraform no more makes you “cloud agnostic” than using Python to script AWS services and calling boto3 than using bash and calling the AWS CLI.
Terraform is not an abstraction on top of multiple cloud providers, you work with aws, azure etc explicitly. It is , however, agnostic in the sense that you can provision aws, azure, gcp, etc resources within the same iac project
Hm, we have a few very repetitive terraform projects to setup structured infrastructure clusters. For those, we just use ansible with a bunch of templating to generate a configurable, HCL-based terraform module and version that.
It's a bit of an "Caveman solve problem with rock" approach, but for very regular projects it's great. A new cluster is some group vars, larger changes to the structures can be easily reviewed - and if you really really have to, you can also just modify the generated code by hand to fix something your generation code can't deal with right now.
The value for TFCDK was Developers don't have to learn another language, they can just continue to use existing language they already know.
Downsides are doing infrastructure in a programming language was always problematic unless developer was skilled at Ops which most who used TFCDK were not.
I ought to have phrased it I guess as "I don't agree with the value proposition", mainly because of the downside you point out. This seems superior to Pulumi, though, in that the abstraction is (was) at least owned by Hashicorp so there was less likelihood of it falling out of date and giving you footguns.
Not gonna lie Terranix has been working great for us, all our configuration is in Nix files anyway so it's so easy to just pass stuff in rather than using Tf variables etc
This is a bummer. I don't particularly like Pulumi but use it anyways because for my use cases being able to write actual code is really impactful. Sucks to see fewer options in that space
The often excluded option is dynamically generating JSON and feeding that to TF instead of HCL.
You can combine it with tools like Dhall or my personal preference Jsonnet instead of imperative languages for an interesting experience for reusable pieces outside of module concepts.
It’s not an alternative at all. Terraform CDK is basically TypeScript transpired to HCL. You can codegen TypeScript bindings for any provider. And then write normal TypeScript.
we're using cdk since 100% of our stuff is in aws but will soon need to hook up some external resources like cloudflare. looked at tfcdk a while back but didn't think it was a good idea (glad). still trying to figure out a good way forward and hoping it's not to rip the bandaid and migrate everything to terraform / pulumi
That’s a real shame. It seems like Pulumi is the only alternative for internal DSLs for IaaC? I always found HCL to be quite terrible, slowly becoming less painful, but not really refactoring-friendly.
Terraform CDK had promise as a blessed infrastructure-as-actual-code solution from the official maintainer of Terraform, so easier to sell internally rather than something from a new vendor like Pulumi. I feel sorry for those teams who have migrated to TF CDK.
It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame.
I did try Pulumi a while back, but the compatibility with Terraform modules was not great, so I've switched to CDKTF, which can handle unmodified modules. Dunno if I'll switch back to Pulumi or just use OpenTofu directly.
> It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame.
All their branding does this now, including the HashiCorp logo on their website [0]. There's gotta be a name for this specific branding pattern, but I don't know it.
[0] https://www.hashicorp.com/en/blog/products/terraform
Metastatized branding
I was recently working for a company which got acquired by IBM and we had to do it too. It’s an IBM thing. I bet most people at HashiCorp hate it, at least that was the case for us.
I have absolutely nothing good to say about Pulumi. Stay far, far away.
Why? I’ve had nothing but good experiences, but I don’t run it and the team that does is extremely competent
please expand on this, I am interested (for real!)
Strange, I have a lot of good things to say about both it and Terraform.
Probably some specifics might be more useful there...
We use OpenTofu it’s pretty seamless
Does it do ephemeral values yet?
Yep, as of yesterday’s 1.11 release it’s supported!
That also includes a new “enabled” meta argument, so you don’t have to hack around conditional resources with count = 0.
[0]: https://opentofu.org/blog/opentofu-1-11-0/
Disclaimer: affiliated with the project
How do you migrate from count/for_each to `enabled` ?
You can just switch from `count = 1` to `enabled = true` (or vice-versa, works back-and-forth) for a resource and tofu will automatically move it next time you apply.
It's pretty seamless.
That's cool! We'll still need to change all of the references to `resource[0]`, right? Or does tofu obviate that need as well?
I’m not sure I understand. You refer to the conditional resource fields normally - without list indices. You just have to make sure the object isn’t null.
There’s some samples in the docs[0] on safe access patterns!
[0]: https://opentofu.org/docs/language/meta-arguments/enabled/
Amazing. Good work !
Damn, might finally be able to use it. The lack of ephemeral values was a major blocker.
Now more will be using a combination of OpenTofu and Terraform, and there will probably be some tacit endorsement of OpenTofu by Hashicorp folks in their communication with those who are using both. Good to see!
> It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame.
Or it's legal trying to preempt a risk.
If it was the author just wanting to point at IBM, they'd mention it just once or twice, but using that awkward phrase throughout the text makes me think it was an edit mandated by a careful lawyer.
I was thinking the same thing about the "an IBM company". My guess is that it's a lazy find/replace.
It’s one thing to say it once but 3 times in the same paragraph seems weird for sure!
I assume it's a matter of branding and making IBM look more modern by associating with the Hashicorp brand.
It’s how Red Hat identifies themselves too
This is particularly frustrating as I've spent the last year writing many thousands of lines of CDKTF Python.
HCL just does not have the modularity and expressiveness that Python, or other languages CDKTF supports.
I guess I'll spend another year migrating to Pulumi now..
The lack of expressiveness of HCL is the point and what makes it so good
That's very subjective. Concepts like iterations are inevitable, and they don't look great in a declarative language like HCL.
I also find refactorings considerably harder in a declarative language, since configurations have a rigid structure.
Being able to inherit from Ingress and add a parameter of say public=True/False and then it change annotations, middleware, etc and then being able to re-use that across 100s of stacks is very powerful. DRY is not something HCL is good at.
Getting too clever with an imperative language in what is inherently a declarative domain, is an idea bad enough that they invented a whole new language to avoid you doing it. But some lessons have to be learned the hard way I guess
Yet said language continues to add imperative-inspired constructs to make up for its limitations..
The end result is still declarative, your just using an imperative language to keep your IaC DRY.
If you have the expertise and restraint to not go off the rails, I agree, imperative is more powerful. That plan does not survive teams of sizes over 2 in the majority of cases.
Well that sucks for me.
Rug pulls on infrastructure components seem even worse than other rug pulls as they can hit your entire infra codebase at once
This is why infrastructure people are conservative by nature, it's so damn much gruntwork to migrate without downtime
And it happens while we are all very enthusiastically dedicated to migrating off Kubernetes ingress-nginx. Just as planned.
As an Infrastructure Engineer who used it: I blame people who didnt help fund/maintain it (including ourselves)
"Will be sunset on Dec 10"... commit date: Dec 10.
That seems like rather short notice.
Damn, what are the best alternatives here? For pure AWS I guess CDK directly is okay, but locks you in.
I went with CDK, I'm locked into AWS already and it means my major dependency for IaC is my cloud vendor and not a third party.
If I really need to migrate off of AWS at some point I'll throw an LLM at it.
Exactly. It's just so much cleaner to do it in the Cloud provider's native tooling. The impedance mismatch from Cloud-agnostic abstractions always just makes thing shitty enough that in the long run you spend more time dealing with weird edge cases.
Besides, actual full-scale Cloud migrations are exceedingly rare.
I always hated this meme. Using Terraform no more makes you “cloud agnostic” than using Python to script AWS services and calling boto3 than using bash and calling the AWS CLI.
Terraform is not an abstraction on top of multiple cloud providers, you work with aws, azure etc explicitly. It is , however, agnostic in the sense that you can provision aws, azure, gcp, etc resources within the same iac project
Hm, we have a few very repetitive terraform projects to setup structured infrastructure clusters. For those, we just use ansible with a bunch of templating to generate a configurable, HCL-based terraform module and version that.
It's a bit of an "Caveman solve problem with rock" approach, but for very regular projects it's great. A new cluster is some group vars, larger changes to the structures can be easily reviewed - and if you really really have to, you can also just modify the generated code by hand to fix something your generation code can't deal with right now.
Just use Terraform?
Yeah I'm struggling to see the value here.
The value for TFCDK was Developers don't have to learn another language, they can just continue to use existing language they already know.
Downsides are doing infrastructure in a programming language was always problematic unless developer was skilled at Ops which most who used TFCDK were not.
I ought to have phrased it I guess as "I don't agree with the value proposition", mainly because of the downside you point out. This seems superior to Pulumi, though, in that the abstraction is (was) at least owned by Hashicorp so there was less likelihood of it falling out of date and giving you footguns.
If you want maximal complexity use Crossplane. :P
Probably Pulumi
Terranix? ;-)
Not gonna lie Terranix has been working great for us, all our configuration is in Nix files anyway so it's so easy to just pass stuff in rather than using Tf variables etc
Yes, the NixOS module system is so much more composable than the TF one
At least they gave us some notice, that’s much appreciated.
This is a bummer. I don't particularly like Pulumi but use it anyways because for my use cases being able to write actual code is really impactful. Sucks to see fewer options in that space
The often excluded option is dynamically generating JSON and feeding that to TF instead of HCL.
You can combine it with tools like Dhall or my personal preference Jsonnet instead of imperative languages for an interesting experience for reusable pieces outside of module concepts.
Any particular libraries you use to generate TF-JSON from jsonnet?
I wrote a generator a little while ago that can create jsonnet libraries from the TF schemas: https://github.com/Duologic/soysonnet
Example lib here: https://github.com/Duologic/soysonnet-aws
I only needed it for AWS so I didn't spend more time on it.
As an alternative is anyone considering https://sst.dev/ (which uses Pulumi under the hood)? We use it at work and I’ve been quite happy with it
It’s not an alternative at all. Terraform CDK is basically TypeScript transpired to HCL. You can codegen TypeScript bindings for any provider. And then write normal TypeScript.
This is so sad. It’s a great project. Needs to be forked and maintained. If anyone forks please email me I’ll contribute.
Hashicorp, an IBM company
Hashicorp,an IBM company
we're using cdk since 100% of our stuff is in aws but will soon need to hook up some external resources like cloudflare. looked at tfcdk a while back but didn't think it was a good idea (glad). still trying to figure out a good way forward and hoping it's not to rip the bandaid and migrate everything to terraform / pulumi
It would be great to have an alternative to Terraform that uses a bit more advanced provider (at last for AWS). Does OpenTofu use that same provider?
The providers for tofu are by design the same as for terraform.
Also, for large providers like AWS, GCP, Azure, etc - these are often largely authored by the hyperscaler themselves, for better or worse.
It does. What are you looking for in a more advanced AWS provider?
That’s a real shame. It seems like Pulumi is the only alternative for internal DSLs for IaaC? I always found HCL to be quite terrible, slowly becoming less painful, but not really refactoring-friendly.
Terraform CDK had promise as a blessed infrastructure-as-actual-code solution from the official maintainer of Terraform, so easier to sell internally rather than something from a new vendor like Pulumi. I feel sorry for those teams who have migrated to TF CDK.
Internal vs external DSLs explained in the middle of this page: https://martinfowler.com/bliki/DslQandA.html
Kubernetes has a few things, including cdk8s. Yoke looks promising too.
Good move. They clearly didn't have the resources they needed. The design of the CDKs was atrocious.
What was the point of it? Terraform supports AWS anyway.