Hacker News Reader

Comment by alexey-salmin | Hacker News Reader

The topic is indeed very interesting but before studying commit author diversity it would be useful to understand the volume and traction. Statistically most of the forks are dead ends, even if maintained by a few enthusiasts for some time.

I'm sure opensearch won't die until it's a commercial offering of AWS but how is going? Any new features coming, a product roadmap exists? Or it's mainly bugfixes and maintenance? What about Opentofu?

Even something basic like a graph of LOC changed over time, with a fork in the middle would help to put the article into perspective.

View on HN

OpenTofu is doing really well I'd say, and only picking up steam as it's going.

Product roadmap-wise, the team has made some big improvements that have been requested by the community for years, with another big release coming very soon (I believe next week or the one after), here's some of the major ones:

- End-to-End State Encryption - lets you encrypt your state-file end-to-end, either with a key management system like AWS KMS, or static keys.

- Early Evaluation - the ability to parameterize initialiation-time values, like module versions and sources, backend configuration parameters, etc. and keep them DRY.

- (Coming in 1.9) - provider iteration, which lets you use for_each with providers, e.g. create one provider per region, something that currently requires a bunch of copy-paste, or tools like Terragrunt

- (Coming in 1.9) - -exclude flag, which is the opposite of the -target flag, letting you skip planning/applying certain resources.

Probably the best way to see a summary is check out the release blog posts for 1.7[0], 1.8[1], and 1.9-beta[2]. Many of those required non-trivial changes to existing parts of the codebase.

One of the biggest Terraform contributors has also joined Spacelift a couple months ago to work on OpenTofu. All things considered, I'm very confident that the team will be able to handle any feature it sets their minds to, and that those improvements will keep coming. There's a ranking of top-voted issues which is probably the best way to loosely see what will be tackled next[3].

[0]: https://opentofu.org/blog/opentofu-1-7-0/

[1]: https://opentofu.org/blog/opentofu-1-8-0/

[2]: https://opentofu.org/blog/opentofu-1-9-0-beta1/

[3]: https://github.com/opentofu/opentofu/issues/1496

Disclaimer: I am involved in the OpenTofu project and was previously its tech lead.

Provider iteration is a really nice one - I had a big monorepo that would deploy some baseline services in many AWS accounts, across multiple regions, generating tf.json files for each provider to match all accounts that were created.

However, what really broke this model at some point was the fact that we were running so many providers instances that our Terraform Cloud would go out of memory! Since each provider instance in tf is really launching a new process it really adds up... At some point I was thinking since the engine and the providers use gRPC to communicate, it MAY be possible to distribute providers across machines, but I never investigated it further... I'm pretty sure there was a notice in the tf plugin SDK stating that it was not possible to connect them over a network... but why not? ¯\_(ツ)_/¯

Yeah, esp. the AWS provider is pretty memory-intensive.

I believe someone on the team did some investigation into this (running providers remotely) but it's not really a priority (if it is for you, feel free to voice that on the issue tracker!).

Frankly though, with pricing for cloud instances being generally linear wrt to the CPU/memory size of the instance, I don't think there's much reason to prefer many smaller machines over just using a larger single one and avoiding all this added complexity.

We’re just migrating to OpenSearch from Xapian and it was one of the question we had. We didn’t want to go from a solution in maintenance mode to one which could be a dead end soon.

From what we’ve seen there is lots of active development going on with many features being added.

But we don’t yet use any fancy features and could easily switch to ElasticSearch if need be. So we got a backup plan.

> But we don’t yet use any fancy features and could easily switch to ElasticSearch if need be.

I think the decision paralysis is the big deal here. I have the exact same situation with OpenTofu and Terraform, they're diverging rapidly yet it's not entirely clear which way the wind is blowing. They both now have compelling and interesting features that the other doesn't have.

So the outcome is that I'm now not using any new features.

I think many people have been in this situation.

In practice, and I'm extremely biased here, I'd consider the most risk-averse option to be going with OpenTofu but not using any of its exclusive new features. With this you get dependency updates and the widest competitive range of vendors in case you ever want to use a commercial orchestrator service for it.

However, it seems to me folks at companies of all sizes are increasingly deciding to bite the bullet and migrate, esp. since the last release a couple months ago. E.g. see the talk by Fidelity[0] on OpenTofu Day at Kubecon.

[0]: https://youtu.be/7Ypulc2GyoE

Disclaimer: I am involved in the OpenTofu project and was previously its tech lead.

Reply on news.ycombinator.com