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.
jjice 142 days ago [-]
> 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.
It’s endorsed branding. Basically when a parent company “endorses” its subsidiaries’ brands, but keep their own name (as opposed to renaming everything to IBM, like eg Google would do).
huddo121 142 days ago [-]
Metastatized branding
142 days ago [-]
pretext-1 142 days ago [-]
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.
dandellion 142 days ago [-]
Makes IBM look really bad. Do they also force people to bow when the CEO of IBM enters the room, and address them as sir or your highness?
miki123211 142 days ago [-]
They used to have their employees sign songs praising the company...
Granted, that was in the 1930s or something, but still.
abhiyerra 141 days ago [-]
I remember it being a part of the movie Pirates of Silicon Valley and thought it couldn’t be true. But apparently it was.
I have absolutely nothing good to say about Pulumi. Stay far, far away.
willio58 142 days ago [-]
My experience with Pulumi is you can write bad pulumi code and good pulumi code and just like everything else, it's easy to end up in a codebase where one poor soul was tasked with writing it all and they didn't do the best job with it.
here2learnstuff 141 days ago [-]
Please expand on your experiences, because I've had great luck with Pulumi at my company since October 2021. No engineer liked HCL, our demographic was engineers who were familiar with programming languages who wanted to self service basic infrastructure (AWS SecretsManager, IRSA roles, Databricks Service Principals, etc). We were pretty easily able to shim in a RunAtlantis inspired system that displayed previews that required explicit approval when a PR was raised, performed apply on merge to main, and ran drift checks periodically.
Garlef 141 days ago [-]
Their stack builds a lot of abstractions on top of each other and this works only well as long as you don't deviate from the beaten path.
One example:
You can't really build custom TS providers for AWS resources.
Why?
Because this feature is built using the compilation magic that makes inline lambdas work.
But the compilation step omits the AWS SDKs since these are present in a lambda anyways. So you can't use the AWS SDK in custom providers.
lokar 141 days ago [-]
For me, the ideal is each team owns its own config/lifecycle mgmt, and does it in the language they wrote the rest of the system in.
weakfish 142 days ago [-]
Why? I’ve had nothing but good experiences, but I don’t run it and the team that does is extremely competent
jen20 142 days ago [-]
Strange, I have a lot of good things to say about both it and Terraform.
Probably some specifics might be more useful there...
142 days ago [-]
katdork 141 days ago [-]
My experience is that by stealing providers from Terraform, they failed to properly handle statically typed languages (Go) with certain providers (HCloud); I had problems with their ID type and had to abandon my Pulumi setup.
purpleidea 141 days ago [-]
Have a look at https://github.com/purpleidea/mgmt/ and tell me what you think. We don't have enough docs though. Tough being an open source thing that you want to keep open.
lighthazard 141 days ago [-]
Running SST with Pulumi and it's been a great experience. Infrastructure and maintenance has been pleasant and SST's pre-fabs really make things easy to spin up resources.
mfornasa 142 days ago [-]
please expand on this, I am interested (for real!)
smithcoin 142 days ago [-]
We use OpenTofu it’s pretty seamless
benatkin 142 days ago [-]
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!
Hamuko 142 days ago [-]
Does it do ephemeral values yet?
cube2222 142 days ago [-]
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.
How do you migrate from count/for_each to `enabled` ?
cube2222 142 days ago [-]
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.
joombaga 142 days ago [-]
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?
cube2222 142 days ago [-]
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!
And you don't get the annoying array form for the resulting resource with the `enabled` syntax, right?
EDIT: Oh just realized the sibling asked the same, but the doc doesn't state that clearly, although it seems to me that the doc implies that yeah, it doesn't use the array form anymore.
cube2222 141 days ago [-]
Yes indeed! It does not use the annoying array form.
darkwater 140 days ago [-]
Worth switching to Opentofu only for this, then! I fuckin hate the count pattern for conditional present/not present that leads to an array of size == 1.
lijok 142 days ago [-]
Amazing. Good work !
Hamuko 142 days ago [-]
Damn, might finally be able to use it. The lack of ephemeral values was a major blocker.
atonse 142 days ago [-]
I was thinking the same thing about the "an IBM company". My guess is that it's a lazy find/replace.
Pet_Ant 142 days ago [-]
I assume it's a matter of branding and making IBM look more modern by associating with the Hashicorp brand.
cr125rider 142 days ago [-]
It’s one thing to say it once but 3 times in the same paragraph seems weird for sure!
selkin 142 days ago [-]
> 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.
nsonha 141 days ago [-]
"Hashicorp, an IBM company"
Common sense would be IBM mandating that branding, as opposed to Hashicorp.
roboben 141 days ago [-]
They should have renamed it first to HashiCorp, an IBM Company CDK, then shut it down
firesteelrain 142 days ago [-]
It’s how Red Hat identifies themselves too
viraptor 142 days ago [-]
It's common when corps buy large enough companies that they don't want to kill the original brand. That's why you get hotels like "(something) by Hilton".
richardfontana 142 days ago [-]
Do you mean Red Hat identifies itself using the phrase "Red Hat, an IBM Company"? Because I don't see any use of this on redhat.com (including that website's corporate "about" content) and if any Red Hatters are using this phrasing (I'm a current Red Hat employee) I haven't been aware of it.
firesteelrain 141 days ago [-]
I have seen it in several articles. (I don’t work for HashiCorp or Red Hat subsidiaries so no idea what is said or done inside those subs)
You said "It’s how Red Hat identifies themselves too" but those two articles are not by Red Hat. So ... it's not how Red Hat identifies themselves, though it seems to be how Hashicorp identifies themselves.
crimsonnoodle58 142 days ago [-]
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..
lijok 142 days ago [-]
The lack of expressiveness of HCL is the point and what makes it so good
crimsonnoodle58 142 days ago [-]
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.
lijok 142 days ago [-]
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
everforward 142 days ago [-]
The problem is they did an exceptionally poor job at designing their language. A reasonably large Terraform codebase is almost universally hard to read for one of two reasons: it's either unexpressive (read: verbose to the point it's hard to read) or modularized but hard to read because it's fragmented into a bajillion reusable modules.
SQL is also declarative, but incredibly expressive. A thousand character query contains enough complexity that it's hard to reason about. A thousand characters of Terraform will barely stand up a CRUD app on AWS.
Designing a language from first principles for this was a mistake. HCL is awful; they should have gone the Starlark route and made a stripped-down version of an existing language instead of making their own language from scratch. This feels like the worst of both worlds. The language is practically imperative, but it has its own syntax that isn't useful outside of this one single domain.
solatic 141 days ago [-]
> reasonably large
Anyway you shouldn't have too many resources in a single Terraform workspace, for performance reasons. The real issues with Terraform come when you start to want to orchestrate different workspaces triggering each other, and trying to write that orchestration language, which itself would be declarative.
Terraform built a Stacks feature, but support is Terraform Cloud-only. OpenTofu has issues in the area that have been open for years: https://github.com/opentofu/opentofu/issues/931https://github.com/opentofu/opentofu/issues/2860 and progress is slow, in part (IMO) because a genuine solution requires server-side evaluation (i.e. triggering applies as Kubernetes Jobs) and the open-source implementation of Terraform Enterprise/Cloud is a completely separate project with a completely different group of maintainers, Terrakube.
Uvix 141 days ago [-]
I'd argue the real issue with Terraform is that workspace orchestration is necessary in the first place. If they addressed the performance issues with large workspaces, then we wouldn't need to split up workspaces and Terraform could just orchestrate changes naturally.
solatic 141 days ago [-]
The performance issues in large workspaces are due to needing to refresh status on all the resources in the large workspace before coming up with a plan. Actual apply time is either negligible or the inherently long amount of time it's supposed to take.
You split the workspace into smaller workspaces precisely to tell Terraform that you haven't made any changes to the networking layer, so don't bother trying to refresh the status of the networking layer to see if any changes are needed, it's not relevant when you're trying to scale up your Kubernetes cluster or whatever.
pxc 142 days ago [-]
Declarative vs. imperative doesn't have anything to do with power or expressiveness. Some general purpose programming languages are declarative, and some declarative DSLs are Turing-complete.
I worry that comments like this lead the average newbie to overlook (or worse, avoid) declarative languages (both among DSLs and among general-purpose languages) because they will associate the term with hacky, confining, gotcha-ridden messes like Terraform's HCL, Azure DevOps' standards-breaking "YAML" DSL, etc.
Incidentally I agree that a language like Python is a terrible fit for this domain, but it's also plain to see that HCL is a shitty tarpit. It's not hard to understand why people want to get away from HCL.
And concretely, you can use Pulumi in a pure functional style with F# or Scala.
dastbe 142 days ago [-]
They invented a language to avoid you imperatively updating infrastructure, but that's not what CDKTF does; it just makes it easier to materialize that declarative output.
It also makes it easier to reason about that output as you can avoid awkward iteration in your declarative spec.
crimsonnoodle58 142 days ago [-]
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.
lijok 142 days ago [-]
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.
Spivak 142 days ago [-]
But it's not even imperative. Your code runs, declares all its resources up front and then normal terraform runs on it. With cdktf you can even have it output the HCL.
At the point where we are templating Terraform files we've already lost the plot. You might as well get to use a real programming language.
theevilsharpie 142 days ago [-]
I have used Terraform, Puppet, Helm, and Ansible (although that's not strictly declarative), and all of them ran into problems in real-world use cases that needed common imperative language features to solve.
Not only does grafting this functionality onto a language after-the-fact inevitably result in a usability nightmare, it also gets in the way of enabling developer self-service for these tools.
When a developer used to the features and functionality of full-featured language sees something ridiculous like Terraform's `count` parameter being overloaded as a conditional (because Terraform's HCL wasn't designed with conditional logic support, even though every tool in this class has always needed it), they go JoePesciWhatTheFuckIsThisPieceOfShit.mp4 at it, and just kick it over to Ops (or whoever gets saddled with grunt work) to deal with.
I'm seeing the team I'm working with going down that same road with Helm right now. It's just layers of templating YAML, and in addition to looking completely ugly and having no real support for introspection (so in order to see what the Helm chart actually does, you essentially have to compile it first), it has such a steep learning curve that no one other than the person that come up with this approach wants to even touch it, even though enabling developer self-service was an explicit goal of our Kubernetes efforts. It's absolutely maddening.
bigstrat2003 142 days ago [-]
That is... not a good idea at all imo. It's very, very easy to over-DRY infrastructure config and it sounds like you're well past that point.
JojoFatsani 142 days ago [-]
Make a module
pizza234 142 days ago [-]
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.
vanschelven 142 days ago [-]
"Will be sunset on Dec 10"... commit date: Dec 10.
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.
Kubernetes has a few things, including cdk8s. Yoke looks promising too.
jeroensoeters 142 days ago [-]
[dead]
mfornasa 142 days ago [-]
Rug pulls on infrastructure components seem even worse than other rug pulls as they can hit your entire infra codebase at once
lillecarl 142 days ago [-]
This is why infrastructure people are conservative by nature, it's so damn much gruntwork to migrate without downtime
mfornasa 142 days ago [-]
And it happens while we are all very enthusiastically dedicated to migrating off Kubernetes ingress-nginx. Just as planned.
preisschild 142 days ago [-]
As an Infrastructure Engineer who used it: I blame people who didnt help fund/maintain it (including ourselves)
kennu 141 days ago [-]
Sad to see it go. The philosophy of CDK has been to offer a shared ecosystem between IaC, backend code and frontend code, allowing to share configuration, data structures and libraries between all of them. It has made development more unified and have less redundancy and manual work. Personally I don't want to repeat some stuff in a special Terraform language, if I can find a way to manage the whole application in TypeScript.
theknarf 141 days ago [-]
Pulumi
kennu 141 days ago [-]
Thanks, will definitely look into it. I first used Pulumi when it was just a cloud platform but seems it is a more general devops tool now.
GardenLetter27 142 days ago [-]
Damn, what are the best alternatives here? For pure AWS I guess CDK directly is okay, but locks you in.
tapoxi 142 days ago [-]
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.
manquer 142 days ago [-]
IaaC code is one of those use cases just throwing LLM is painful for a refactor.
In my experience claude/codex to wrangle CDK constructs be complicated, it frequently hallucinates constructs that simply do not exist, options that are not supported etc.
While they can generate IaaC component mostly okay and these problems can be managed, Iterations can take a lot of time, each checkpoint, goes the deploy/ rollback cycles in CF. CloudFormation is also not particularly fast, other IaaC frameworks are not that different.
Running an agent to iterate until it gets it right is just more difficult with IaaC refactor projects. Hallucinations, stuck loops and other issues, can quickly run the infra bill up not to mention security.
manishsharan 141 days ago [-]
I had Gemini ingest our huge aws cloudformation repo . I had it describe each infrastructure component and how it related to others and creation hierarchy and IAM.
I got a nice and comprehensive infrastructure requirement document out of this.
Now I am using it to create Terraform repo , deploying it via OpenTofu and comparing it to my existing AWS cloud formation . This part is still a WIP .
raw_anon_1111 141 days ago [-]
I have used ChatGPT to generate perfect IaaC using the CDK and Terraform. I give it my labelled descriptive design diagram that I have to do anyway.
I am very detailed about all of the security group requirements, tell it that I don’t need Internet access and tell it which VPC endpoints. I don’t do “agentic coding”.
ryandvm 142 days ago [-]
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.
emoII 142 days ago [-]
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
raw_anon_1111 142 days ago [-]
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.
thayne 141 days ago [-]
AWS's native tooling is Cloudformation, and CDK is actually just a wrapper around that that generates cloudformation code (as CDKTF is a wrapper for terraform). And I like to avoid cloudformation as much as possible.
GuinansEyebrows 141 days ago [-]
writing HCL is so much more enjoyable than writing CF, even if HCL is fairly verbose (hey, it's not as bad as XML!). CF feels like a series of PM requirements dutifully codified with no dogfooding whereas HCL/TF feels like a tool that was developed by people who actually wanted to use it.
exidy 140 days ago [-]
> but locks you in
Not picking on you personally but having had this conversation many times over many years with many clients I find it confounding. Oftentimes TF itself was heavily promoted as a way of "avoiding lock in".
Well guess what? Now you're locked-in to IBM, whose motivations may not be perfectly aligned to you goals of simply and efficiently using your cloud provider of choice to deliver your business outcomes.
What we refer to as lock-in is simply an expression of risk, with one axis being the cost of getting off $solution and the other being the likelihood of needing to do so. Having stepped through this exercise a few times, the cost of rewriting your e.g. AWS API Gateway + Lambda + SQS + RDS + CloudWatch etc architecture invariably vastly dwarfed the cost of changing the IaC language it is expressed in.
Anytime you feel the urge to overbuild on a cloud provider's services, stop, and do a really rigorous cost/benefit analysis. If you truly have unique drivers the data should tell the story.
rendaw 141 days ago [-]
I made https://github.com/andrewbaxter/terrars ! It's great! You get more benefits if you're in a Rust project (obviously) but it has some things that make it a good alternative anywhere:
- More accurate types/type safety than the CDK (for static feedback on required parameters, etc)
- No CLI required - just plain Rust (provider definitions can be published as normal rust packages so you don't have to generate them yourselves, and I've published a bunch of common ones - docker, aws, etc)
- Simpler: Terraform CDK had this crazy flow where it (go code) generated typescript code then used some transpiler to generate target language code. The output wasn't pretty, and there were bugs. Your project directory would get filled with boilerplate generated files.
It generates tf json files and has a fairly safe way for handling variable interpolation and escapes - I haven't hit any weird bugs with it.
tetha 142 days ago [-]
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.
scruff3y 142 days ago [-]
Just use Terraform?
rendaw 141 days ago [-]
The value of CDK was always that it allowed you to write in a fully orthogonal language rather than the poor pseudo-language of hcl.
When writing stacks you need normal language features: loops, yes, but also if statements, reuse (functions), being able to do stuff like complex string parsing and re-formatting, etc etc.
HCL supports loops, modules can be kind-of used as functions with lots of footguns, there are awful hacks for some other things, and some stuff just couldn't be done.
142 days ago [-]
cholantesh 142 days ago [-]
Yeah I'm struggling to see the value here.
stackskipton 142 days ago [-]
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.
cholantesh 142 days ago [-]
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.
coenhyde 142 days ago [-]
That might have been the promise but never the real value. As you say in practice the engineer needs to know ops & terraform along side their language of choice.
The real value of cdktf was more dynamic infrastructure provisioning while still having the plan / apply pattern.
mfornasa 142 days ago [-]
Probably Pulumi
resonious 142 days ago [-]
I'll be honest Pulumi is pretty cool but I'm a little worried by how high on the stack it is. I wonder if the same thing won't happen to them that's happening to CDKTF here.
Terraform is ugly but it works well enough for me and seems ingrained enough to be durable to this kind of thing (i.e. I bet for sure the community would pick it up (I wish I could say that I'm part of that community but I can't say I use it quite that often))
re-thc 142 days ago [-]
> I wonder if the same thing won't happen to them that's happening to CDKTF here.
This is clearly a business decision rather than technical.
Pulumi is meant to be semi-automated (in generating the bridges) so perhaps is slightly better off in maintenance.
srmatto 142 days ago [-]
If you want maximal complexity use Crossplane. :P
sshine 142 days ago [-]
Terranix? ;-)
lillecarl 142 days ago [-]
Yes, the NixOS module system is so much more composable than the TF one
madjam002 142 days ago [-]
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
theknarf 141 days ago [-]
Normal Terraform, Pulumi or OpenTofu
rweichler 140 days ago [-]
As a complete noob to the space, as an individual, who doesn't care about being "hireable" or whatever, which one has the highest ROI? OpenTofu?
an-engineer 137 days ago [-]
There are active discussions in the https://cdk.dev/ Slack channel #terraform-cdk about building community-driven forks of the existing Hashicorp/IBM CDKTF repositories. A number of developers who work at organizations that are heavily reliant on CDKTF have offered to pitch in.
And one Open Tofu developer said he and some other Open Tofu developers would be happy to collaborate with that community-driven effort to keep CDKTF alive:
"The OpenTofu maintainers are happy to collaborate with that project once it's up and running, but we will not be directly involved."
https://github.com/opentofu/opentofu/issues/3585
deadfece 142 days ago [-]
At least they gave us some notice, that’s much appreciated.
breakingcups 140 days ago [-]
Define "some"
deadfece 137 days ago [-]
Oh I don't know, 2? or 3?
paulddraper 137 days ago [-]
2 or 3 what?
NeckBeardPrince 142 days ago [-]
Hashicorp, an IBM company
tonnydourado 142 days ago [-]
Hashicorp,an IBM company
chickensong 142 days ago [-]
Hashicorp, an IBM company
egorfine 141 days ago [-]
Hashicorp, an IBM company
Havoc 142 days ago [-]
As far as corporate mercy killings goes archived under mozilla license is better than a pivot to "you now pay per core" or whatever
borisbanjo 142 days ago [-]
CDKTF works beautifully, all the complains here seem to be from salty devops who got pissed the developers wanted something more powerful than the garbage HCL with its even more garbage module system.
CDKTF stacks are great and the construct pattern gives you modularization without all the baggage.
nevon 141 days ago [-]
Not stated in the most diplomatic way, but I do agree. Having used CDK (not cdktf) and now being forced back to Terraform feels like going back to the stone age. It is absolutely obvious to me that generating infrastructure definitions from a regular, testable language using all the same tools, techniques and distribution mechanisms that you use for all your other software development is the superior way. Being able to piggyback off of the vast ecosystem of Terraform providers was a really clever move, although I understand it led to some rough edges.
nijave 142 days ago [-]
I kind of like it but I always found it kind of clunky how it's ultimately just generating JSON/HCL anyway. For instance, you can't data source then use code to transform and send it to a resource since it has to transpile first.
That also means you end up with things like the language's native JSON not doing what you expect and having to use a special Terraform function call.
zer0-c00l 142 days ago [-]
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
leetrout 142 days ago [-]
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.
Duologic 142 days ago [-]
Any particular libraries you use to generate TF-JSON from jsonnet?
I only needed it for AWS so I didn't spend more time on it.
leetrout 141 days ago [-]
By hand :( But I like your project. Do you use Tanka?
Duologic 141 days ago [-]
I work at Grafana and did quite a bit of work on Tanka in the past, so yes.
joeduffy 142 days ago [-]
[Pulumi founder here] Sorry to hear you don't particularly like Pulumi---any/all feedback welcome. If nothing else, we do listen and we do try to get better. -Joe
here2learnstuff 141 days ago [-]
What is it that you don't like about Pulumi? As I mentioned in another comment, my team of backend-engineers who took over an infra team went from Cloudformation -> CDK -> Terraform -> Pulumi and honestly find it the most approachable for other engineers familiar with normal programming languages (sorry HCL). We've been using it since 2021 and have a "what's on main is what's deployed" philosophy and adopted a RunAtlantis inspired workflow where previews are run as status checks on PRs and require explicit approvals, apply is run on merge to main and periodically, and drift checks run preview+refresh and alerts if what's checked in doesn't match what exists. We don't really use stacks, we just use a separate project for everything and write code to encapsulate modules (and luckily we can easily write unit tests and runtime assertions).
moltar 142 days ago [-]
This is so sad. It’s a great project. Needs to be forked and maintained. If anyone forks please email me I’ll contribute.
rubenvanwyk 141 days ago [-]
OpenTofu is already the de facto fork.
thayne 141 days ago [-]
OpenTofu is a fork of terraform, not CDKTF.
Although, I would hope a fork of cdktf would target opentofu instead of terraform.
callumgare 142 days ago [-]
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
moltar 142 days ago [-]
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.
ptdorf 141 days ago [-]
> Terraform CDK is basically TypeScript transpired to HCL
transpiled to JSON
dev_l1x_be 142 days ago [-]
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?
jpitz 142 days ago [-]
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.
lijok 142 days ago [-]
It does. What are you looking for in a more advanced AWS provider?
dev_l1x_be 140 days ago [-]
Have you ever debugged what goes on with lets say the aws provider during a tf apply?
kbar13 142 days ago [-]
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
DangitBobby 142 days ago [-]
Well that sucks for me.
lijok 142 days ago [-]
Good move. They clearly didn't have the resources they needed. The design of the CDKs was atrocious.
lloydatkinson 142 days ago [-]
What was the point of it? Terraform supports AWS anyway.
so0k3311 140 days ago [-]
[dead]
Rendered at 14:28:29 GMT+0000 (UTC) with Wasmer Edge.
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.
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
Granted, that was in the 1930s or something, but still.
https://youtu.be/VyQEbLx6AEY?si=CwhqHQEdFGCsE33l
One example:
You can't really build custom TS providers for AWS resources.
Why?
Because this feature is built using the compilation magic that makes inline lambdas work.
But the compilation step omits the AWS SDKs since these are present in a lambda anyways. So you can't use the AWS SDK in custom providers.
Probably some specifics might be more useful there...
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
It's pretty seamless.
There’s some samples in the docs[0] on safe access patterns!
[0]: https://opentofu.org/docs/language/meta-arguments/enabled/
EDIT: Oh just realized the sibling asked the same, but the doc doesn't state that clearly, although it seems to me that the doc implies that yeah, it doesn't use the array form anymore.
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.
Common sense would be IBM mandating that branding, as opposed to Hashicorp.
1. https://business.adobe.com/customer-success-stories/red-hat....
2. https://www.openpr.com/news/4100338/linux-operating-system-m...
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..
SQL is also declarative, but incredibly expressive. A thousand character query contains enough complexity that it's hard to reason about. A thousand characters of Terraform will barely stand up a CRUD app on AWS.
Designing a language from first principles for this was a mistake. HCL is awful; they should have gone the Starlark route and made a stripped-down version of an existing language instead of making their own language from scratch. This feels like the worst of both worlds. The language is practically imperative, but it has its own syntax that isn't useful outside of this one single domain.
Anyway you shouldn't have too many resources in a single Terraform workspace, for performance reasons. The real issues with Terraform come when you start to want to orchestrate different workspaces triggering each other, and trying to write that orchestration language, which itself would be declarative.
Terraform built a Stacks feature, but support is Terraform Cloud-only. OpenTofu has issues in the area that have been open for years: https://github.com/opentofu/opentofu/issues/931 https://github.com/opentofu/opentofu/issues/2860 and progress is slow, in part (IMO) because a genuine solution requires server-side evaluation (i.e. triggering applies as Kubernetes Jobs) and the open-source implementation of Terraform Enterprise/Cloud is a completely separate project with a completely different group of maintainers, Terrakube.
You split the workspace into smaller workspaces precisely to tell Terraform that you haven't made any changes to the networking layer, so don't bother trying to refresh the status of the networking layer to see if any changes are needed, it's not relevant when you're trying to scale up your Kubernetes cluster or whatever.
I worry that comments like this lead the average newbie to overlook (or worse, avoid) declarative languages (both among DSLs and among general-purpose languages) because they will associate the term with hacky, confining, gotcha-ridden messes like Terraform's HCL, Azure DevOps' standards-breaking "YAML" DSL, etc.
Incidentally I agree that a language like Python is a terrible fit for this domain, but it's also plain to see that HCL is a shitty tarpit. It's not hard to understand why people want to get away from HCL.
And concretely, you can use Pulumi in a pure functional style with F# or Scala.
It also makes it easier to reason about that output as you can avoid awkward iteration in your declarative spec.
The end result is still declarative, your just using an imperative language to keep your IaC DRY.
At the point where we are templating Terraform files we've already lost the plot. You might as well get to use a real programming language.
Not only does grafting this functionality onto a language after-the-fact inevitably result in a usability nightmare, it also gets in the way of enabling developer self-service for these tools.
When a developer used to the features and functionality of full-featured language sees something ridiculous like Terraform's `count` parameter being overloaded as a conditional (because Terraform's HCL wasn't designed with conditional logic support, even though every tool in this class has always needed it), they go JoePesciWhatTheFuckIsThisPieceOfShit.mp4 at it, and just kick it over to Ops (or whoever gets saddled with grunt work) to deal with.
I'm seeing the team I'm working with going down that same road with Helm right now. It's just layers of templating YAML, and in addition to looking completely ugly and having no real support for introspection (so in order to see what the Helm chart actually does, you essentially have to compile it first), it has such a steep learning curve that no one other than the person that come up with this approach wants to even touch it, even though enabling developer self-service was an explicit goal of our Kubernetes efforts. It's absolutely maddening.
I also find refactorings considerably harder in a declarative language, since configurations have a rigid structure.
That seems like rather short notice.
[0] - https://news.ycombinator.com/item?id=46192130#46198058
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
If I really need to migrate off of AWS at some point I'll throw an LLM at it.
In my experience claude/codex to wrangle CDK constructs be complicated, it frequently hallucinates constructs that simply do not exist, options that are not supported etc.
While they can generate IaaC component mostly okay and these problems can be managed, Iterations can take a lot of time, each checkpoint, goes the deploy/ rollback cycles in CF. CloudFormation is also not particularly fast, other IaaC frameworks are not that different.
Running an agent to iterate until it gets it right is just more difficult with IaaC refactor projects. Hallucinations, stuck loops and other issues, can quickly run the infra bill up not to mention security.
I got a nice and comprehensive infrastructure requirement document out of this.
Now I am using it to create Terraform repo , deploying it via OpenTofu and comparing it to my existing AWS cloud formation . This part is still a WIP .
I am very detailed about all of the security group requirements, tell it that I don’t need Internet access and tell it which VPC endpoints. I don’t do “agentic coding”.
Besides, actual full-scale Cloud migrations are exceedingly rare.
Not picking on you personally but having had this conversation many times over many years with many clients I find it confounding. Oftentimes TF itself was heavily promoted as a way of "avoiding lock in".
Well guess what? Now you're locked-in to IBM, whose motivations may not be perfectly aligned to you goals of simply and efficiently using your cloud provider of choice to deliver your business outcomes.
What we refer to as lock-in is simply an expression of risk, with one axis being the cost of getting off $solution and the other being the likelihood of needing to do so. Having stepped through this exercise a few times, the cost of rewriting your e.g. AWS API Gateway + Lambda + SQS + RDS + CloudWatch etc architecture invariably vastly dwarfed the cost of changing the IaC language it is expressed in.
Anytime you feel the urge to overbuild on a cloud provider's services, stop, and do a really rigorous cost/benefit analysis. If you truly have unique drivers the data should tell the story.
- More accurate types/type safety than the CDK (for static feedback on required parameters, etc)
- No CLI required - just plain Rust (provider definitions can be published as normal rust packages so you don't have to generate them yourselves, and I've published a bunch of common ones - docker, aws, etc)
- Simpler: Terraform CDK had this crazy flow where it (go code) generated typescript code then used some transpiler to generate target language code. The output wasn't pretty, and there were bugs. Your project directory would get filled with boilerplate generated files.
It generates tf json files and has a fairly safe way for handling variable interpolation and escapes - I haven't hit any weird bugs with it.
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.
When writing stacks you need normal language features: loops, yes, but also if statements, reuse (functions), being able to do stuff like complex string parsing and re-formatting, etc etc.
HCL supports loops, modules can be kind-of used as functions with lots of footguns, there are awful hacks for some other things, and some stuff just couldn't be done.
Downsides are doing infrastructure in a programming language was always problematic unless developer was skilled at Ops which most who used TFCDK were not.
The real value of cdktf was more dynamic infrastructure provisioning while still having the plan / apply pattern.
Terraform is ugly but it works well enough for me and seems ingrained enough to be durable to this kind of thing (i.e. I bet for sure the community would pick it up (I wish I could say that I'm part of that community but I can't say I use it quite that often))
This is clearly a business decision rather than technical.
Pulumi is meant to be semi-automated (in generating the bridges) so perhaps is slightly better off in maintenance.
There is currently a live proof of concept fork of the main cdktf repository that one developer made: https://github.com/TerraConstructs/terraform-cdk
And one Open Tofu developer said he and some other Open Tofu developers would be happy to collaborate with that community-driven effort to keep CDKTF alive: "The OpenTofu maintainers are happy to collaborate with that project once it's up and running, but we will not be directly involved." https://github.com/opentofu/opentofu/issues/3585
CDKTF stacks are great and the construct pattern gives you modularization without all the baggage.
That also means you end up with things like the language's native JSON not doing what you expect and having to use a special Terraform function call.
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.
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.
Although, I would hope a fork of cdktf would target opentofu instead of terraform.
transpiled to JSON
Also, for large providers like AWS, GCP, Azure, etc - these are often largely authored by the hyperscaler themselves, for better or worse.