I don't know much about licenses but this seems like a reasonable change? Anyone have a burning disagreement with what Hashi has done? Would be interested in another perspective

The way I understand this is: “only hashicorp can sell terraform-as-a-service from now on, but people can use it for free in production.” Is that correct? If so, totally reasonable…but there will be many people whom this frustrates philosophically.

I think it is broader than that.

Hmm. From the FAQ on the website

Organizations providing competitive offerings to HashiCorp will no longer be permitted to use the community edition products free of charge under our BSL license. Commercial licensing terms are available and can enable use cases beyond the BSL limitations.

yeah

My long term outlook for Hashicorp is not great, and wasn’t before this. They’re really struggling in a lot of areas, Nomad lost to K8s, Consul is losing to Istio, and it seems like even things like Terraform are in danger too

even though they are not TF-as-a-Service strictly speaking.

Open-Source or not, Terraform is still "Free for Production Use" but Pulumi is not

what do you mean?

You can use Terraform in production for free with any State Backend. Pulumi, like Terraform, requires a state backend. There are no implementations other than Pulumi Team/Pulumi Enterprise, unless you want to use a local filesystem-based state backend, which is intractable for production use inside a team.

I'm not following

Terraform State files, which keep track of the state of what infra you've deployed? You can just point it at an S3 bucket which for 99% of use-cases fits within the AWS Free Tier usage limits. Pulumi also needs a state backend. Pulumi (the company) provides one at a cost, which works out to about $4.35 per resource (loadbalancer, VM, VPC, etc) per year. You can implement your own backend, but there are no good docs for how to do so, and it's also quite tricky.

Pulumi can use anything with S3 API, so it is not just local fs, right?

I don't believe that's true, I may be missing something though.

• Robust state management, with transactional checkpointing for fault tolerance and recovery

• Concurrent state locking to prevent corrupting your infrastructure state in a team environment

Oh. It's this ^ which is that's not out-of-the-box with an S3 backend..

This is very very far from "Pulumi is not free for production use"

Hmm. The author of the terraform book (who is prolly biased 😉 ) says it's a non-starter to use without those features, because you could get your state files all screwed up if two people do the equivalent of

terraform apply

at the same time?

maybe, I haven't tested. but again, I think this is a very narrow view. and not at all standard interpretation of "not free for production use".

You could be right. I need to look more heavily into what you don't get with S3.

RedPanda could make the claim that without tiered storage, it isn't safe to run in production and therefore Kafka isn't safe for production use.

😂

It may be "not safe for production when engineers deploy to production from their local branches"... but, this isn't on Pulumi... Production isn't really safe without deployments done via CI/CD...

There’s where my confusion came from

🙂

TIL as well: don't go to a book on Foo to learn about Foo's competitors

it may have been the timing?

I'm not a Pulumi locking expert, so I guess my first mistake was repeating an assertion that I couldn't 100% back up myself...so I don't want to repeat that mistake, not sure I can comment on Pulumi locking. But back to the original question, as a practitioner myself, I am not bothered by the Terraform license change so long as it is legal to continue to use it for free in production.

yeah

Interesting. The book was published in mid-2022, but locking was enabled in 2021. So perhaps the author's knowledge was outdated. The PR you sent seems to suggest that the author's claims are true before the PR and untrue after the PR. However, this is the second edition of the book and the first was published well before the PR came out; Brikman may have simply not double-checked whether the original claim was still true. Two processes (perhaps even a CI server running two merges at once) being able to trip over each other is A Dangerous Thing.

as a practitioner, I'm a bit pissed for few reasons: • Pulumi isn't TF-as-a-Service. They implemented their own everything. But they support compatibility with TF modules. This is good for users. Hashi is punishing them for doing the right thing for their users. • We evaluated TF cloud vs Pulumi. Pulumi is better. If you can't build a better service, try to kill the competition? this is not good for users either. • Pulumi is a smaller and weaker competitor. Much less popular. It is not the same as worrying about AWS, IMO.

OH, now I see. There was a level of nuance I missed here... (coffee isn't a replacement for sleep). Is it that Pulumi Cloud offers a way to integrate terraform modules into users' Pulumi projects? I can see how this change would anger Pulumi users. If I were invested into migrating from TF -> PU, I would be upset too. That's definitely a business decision, and I'm not sure I can blame Hashi for doing that, even though I wish they wouldn't.

It is not Pulumi Cloud. Pulumi SDK itself has a compatibility layer, so if you have a TF module, you can use it.

I don't think it's legal to change the license on existing versions, is it?

right

Last question (I promise).. if there's a module in the central terraform registry, it is no longer possible for someone using Pulumi Cloud to use new versions of that module in their terraform code, since Pulumi Cloud would be redistributing something owned by Hashicorp. Is that correct? On the flipside, someone using Pulumi SDK (unpaid) should be able to do that, since it's not "re-distributing" the TF module.

I am not sure about the details.

I bet you’re right!

Do you know how Crossplane might be impacted? I had understood they wrote their own K8s controllers to provision cloud resources, why would they have a dependency on Terraform?

The cross-plane concerns are related to: https://github.com/upbound/provider-terraform

Ahh interesting, honesty I see this as a good reason to move away from Terraform - I know myself and many others were already looking in that direction anyway. When TF came out there was nothing like it, but the requirements have changed and people want to do things more programmatically that are better enabled by Pulumi & Crossplane. TF CDK is not enough to compete with that

yeah, agree

You can say that about a lot of things in the Hashi stack - Nomad died in a very similar way. Consul is heading down that path. I bet soon Vault gets superseded as well. This feels like an implicit admission by the company that they can’t develop good products, and are now focusing on the code itself as the main value proposition

I miss the good old days where companies competed by building better services for lower prices 😞

One could argue that Istio obviates the necessity for Consul.

No way

Istio & basically every Envoy-based service mesh is wiping the floor with Consul. I interviewed with the Consul team and Solo.io a year ago, and the way they spoke about their product was drastically different

ouch

At this point the only thing I think they’re “leading” in is Vault, but I wouldn’t be surprised if we saw a better competitor pop up soon. The Hashi stack used to be really cool because it all worked so well together, but if 2/3 components are not up to standards it’s not near as attractive anymore

yeah

Are you using Consul + Nomad @Gwen Shapira?

I mean, I’m being a little dramatic - you can definitely still use it. But if I were a betting man, no way am I betting on the Hashi stack based on what I’ve seen the last couple of years. More people want to work on and contribute to Kube/Envoy/Istio and ultimately that’s what tends to win out

K8s does make things so much easier overall. Service discovery, health checks, and DNS all come out of the box along with scaling, quick deployment, and really good resource allocation/sharing primitives.

@Buchi Reddy Busi Reddy not using either right now, but was playing with Consul (and I don't have a Nomad use-case right now)

Are you using ECS, lambda, EC2, or something else?

No lambda yet. Although, this may change by the end of today or tomorrow...

K8s is definitely bloated, I don’t think you’re a tiny minority - I actually think a lot of people would love a better alternative, there just isn’t one at the moment

Curious, what parts of k8s do you think are bloated @Lucas Stephens?

IMO, K8s is bloated and complex because it is very general purpose. And any general purpose solution will have the same problem. I understand the "people should build abstractions on top" idea. But so far these abstractions seem awfully leaky. So I still suffer from the K8s complexity. I don't have much hope for a better general purpose alternative.

From a technical perspective, it’s bloated because it tries to do container orchestration & networking/service discovery all at once. One of the most common bottlenecks is simply the amount of services you can have on a cluster, which if you’re using iptables is ~10K before you start seeing high latency in route propagation. Nomad is so much more scalable because it completely ignores this problem, and assumes you will use a totally separate networking control plane (consul). The rise of “service mesh” is in part due to the rise of K8s because large systems encounter this bottleneck. This is just one example - consider that K8 also has primitives for running stateful workloads, and trying to run any general purpose workload, and you end up with something huge. That’s why there’s a lot of investment into both CSI, CNI, and even CRI projects to extend Kube. But then you’re looking at managing many different components of your cluster architecture. It’s complicated. The good part about K8s is the control plane - and that’s why we’re starting to see more projects like Crossplane “abuse” it to orchestrate & manage resources outside of K8s. As Kelsey Hightower famously says, in the end K8s will just be an API for deploying things

The rise of “service mesh” is in part due to the rise of K8s because large systems encounter this bottleneck.

Are you saying service mesh'es are solving the problem of a lot of services?

Great discussion. I was unrelatedly looking at hashicorp stock but before doing much more research decided half handedly that their products are on the downwards slope re usage. Seems like my intuition was correct