The licensing change is non-consequential for the vast majority of Terraform users. I wish the change didn’t happen, but it’s only a problem for companies that compete directly with HashiCorp’s managed SaaS offerings.
Pulumi is VC backed, pre-exit, and does not use a FOSS license that prevents it from doing the same thing as HashiCorp when the vultures demand more revenue.
I’ve managed cloud infrastructure at several large tech companies and Terraform scales fine. The declarative and immutable aspects of Terraform are constraints that support scaling. If you’re doing something that feels complicated or hacky in Terraform, you’re often doing something that introduces risk into your infrastructure. It’s good to have pain receptors that warn you of danger.
but it’s only a problem for companies that compete directly with HashiCorp’s managed SaaS offerings.
I think the problem that a lot of companies are grappling with is the specifics. What entails “competing”? I think we all understand the spirit of the text, but how could it be interpreted when new management takes over and decides that want to reap every last penny.
a) The spirit is critical. Spirit is what a lawyer ends up arguing in court.
b) I suspect that “competing” is relatively well defined. As an example, when you create your company you have to specify its industry - so at minimum I suspect you can trivially argue “we aren’t even in the same industry” and avoid it. If you’re a SaaS/ software company you’ll need another way to differentiate, but again, I don’t think that’s super complicated unless you’re very very close but (just barely) not actually competing.
I think developers think about legal stuff as if it’s code, and they get so hung up on edge cases and specific hangups, but that’s not really legal shit works in my experience (not a lawyer, but I founded and ran a company for years and we had lawyers, I definitely had to think a lot about legal shit).
Any move that takes us further from clarity is a bad one, even if the legal system has norms that allow people to roll the dice and possibly get a good outcome. What you’re basically saying is: it’s ok that you now need to be able to retain a lawyer just in case to try and fight through the ambiguity in complying with the licence terms. That’s pretty rubbish for all the people who legitimately can’t afford one, and even for the people who can it’s a waste of resources. It’s definitely not open source, and people are right to be sceptical and to give it all a wide berth where possible.
As someone pointed out in the past, the problem is acquisitions. What happens if, say, Amazon or Microsoft buys the company? Are you doing anything that competes with any potential purchaser of the company? If so, you are exposed to legal risk.
I suspect that “competing” is relatively well defined. As an example, when you create your company you have to specify its industry - so at minimum I suspect you can trivially argue “we aren’t even in the same industry” and avoid it.
By this logic, Apple doesn’t compete in the markets for music or, you know, telephones. I’m not a lawyer, but I don’t share your faith that this is a trivial matter at all.
Good article that makes me want to give Pulumi a try. It touches on the pricing, and I agree with the author that Pulumi moving out of resource-based-pricing could help them take a bigger slice of the market.
Usage-based pricing only makes sense when it aligns your provider incentives with yours. The best example here is logs. To reduce your bill, you’ll chase out noisy debug logs, or sample non-error access logs. You don’t lose a ton of value, and your provider’s operational costs are reduced almost linearly
For IaC, you lose a lot more value (by taking some resources out of the managed state, or re-architecturing your stack to optimize on resource count instead of other factors), while your provider only gets a small saving on runner usage.
The real operational cost of IaC providers is not storing the state, but running the plans and apply. If you cannot bill by user like spacelift does, bill by runner minutes like CI providers do. Then, I can split my stack into smaller chunks to reduce runner usage, and my bill.
Billing on managed resource / hour is ludicrous and a non-starter for me.
Try it. I’ve been pushing Pulumi for a few years and would have converted my current company if they hadn’t already started to adopt Terraform shortly before I joined and before I had earned enough credibility. I haven’t touched it in a couple of years now but being able to write your infra code as code and not HCL unlocks a lot.
Having worked at both HashiCorp and Pulumi (one of six ICs on the Pulumi core team until two months ago), this article is very good, both in its criticisms and comparisons.
As someone who used Ansible heavily for ~5 years: Ansible is pretty awful for cloud orchestration. The modules were of very varying quality, the YAML-based configuration gets old really quickly and in general Ansible is just clunky. One example of that clunkiness is how for certain collections you have to manually install dependencies in the target machine for the tasks to work (the one that comes to mind was Azure, where I had to add an explicit step when setting up the VMs to add specific Python packages otherwise the collection wouldn’t work).
It’s a shame, I really wanted to love Ansible, but after that long working with it, I dreaded every time I had to setup a new kind of server.
My impression from (admittedly light) use of ansible and terraform is that anbsible lacks a lot of the state management terraform has. So for example, when deleting an ASG from a terraform module, terraform is smart enough to delete the ASG. But ansible cannot be because it has no memory of what changes is applied in previous runs.
Having had to fight against terraform state in too many occasions, I think that not having one is an advantage in almost all situations. The only case when the state is helpful is the deletion, as you mentioned, and I only had an handful of those.
Drift detection is extremely useful when you have tens of resources that should be identical (or close enough).
Terraform state doesn’t magically fix it, and sometimes even gets in the way of changes, but without it you can’t even know if the actual configurations changed in relation to the intended state.
I’ve never used these sorts of things at anything more than small scale, but… yes you can? You run ansible with the --check --diff flags and it prints out the changes it would need to make to bring your systems into the state specified in the playbook. I’m probably misunderstanding what you mean.
What kinds of situations cause you to have to fight with Terraform state? I’ve been using it for years and the only recurring headache I used to have with state was when I wanted to restructure my configuration (moving things into modules, etc.) which used to require an obnoxious amount of manual state fiddling.
But that was before they added the moved block to support refactoring. Since I started using moved, I can’t remember having to manually mess with a statefile even once.
In my experience, which I hope is uncommon, terraform state rm/pull/push are commands I ended up typing within 1 week of using terraform.
I’ve had issues with:
importing AWS route and route tables with non-sensical errors about the format of the IDs
importing AWS key pairs
deletes actually removing resources but not updating state
specific providers being crap and forcing to manipulate state for trivial changes (the OVH and OpenStack providers want to recreate a VM when you add a network port or an additional storage device)
Manipulating state when moving resources around is perfectly justified in my opinion, but it stems from using state in the first place. If one chooses to interpose a state concept, such as terraform and git, the implementation should be flawless across the entire ecosystem, and from what I’ve seen terraform’s state isn’t.
Which one? I checked digital ocean, aws, azure, gcp, openstack, online, linode and cloudstack.
All of them used python libraries like boto3, azure sdk or google cloud SDK, … Using terraform sounds counter productive, as they would have to fork-exec on a non-built-in binary, when a lot of the cloud providers provide a python SDK.
Last time I checked, Pulumi used Terraform providers in the background for a lot of resouces (might not be true for the super popular ones like AWS). Is that still the case?
It is still the case. Since the providers are under a different license from the core Terraform product, I figured it didn’t matter too much, but yeah if that was a problem for you before it is still there.
Also, the native providers are implemented completely independently from any hashicorp libraries - they’re created directly from the cloud provider’s specifications. The Azure Native provider is now significantly better than the classic (TF-based) provider. The AWS provider is still in preview due to the new AWS API not yet having support for all the key resource types, but this is already very helpful in certain situations where the classic provider falls short.
I hate doing marketing work, but marketing is everything.
All of this is annoying, but I’ve learned to grumble and live with it.
Apparently, Terraform was “good enough ™️” that the author did not spend any time looking for a viable alternative. Fortunately, Pulumi is well positioned to benefit from the HashiCorp license change.
This makes me wonder about Pulumi’s core value proposition: Infrastructure as code in any programming language. No doubt Pulumi has been growing, but I wonder how much market share they were really stealing from Terraform prior to the license change.
This is really cool. I’m a dev, really not super interested in the IAC stuff, definitely not into Terraform (gib code pls). AI is super helpful for stuff like this.
I used Pulumi at my company (Grapl) and it was great tbh
Approximately where does Terraform and Pulumi live on the heptagon of config? And if they can be roughly placed, what are going to expect when moving from one to the other and should we not be surprised when the tradeoffs happen?
idk about Pulumi but in my experience orchestration stuff in general tends to span the “config -> template -> DSL” nodes, with varying levels of emphasis.
You can set up easy APIs. Making a website that generates HCL to stick into a repo and then make a PR? Nightmare. Writing a simple Flask app that runs Pulumi against your infrastructure with scoped permissions? Not bad at all.
Isn’t the difference then that the HCLs repo at least stores expected infrastructure state while the Pulumi API calls are more… ephemeral?
The licensing change is non-consequential for the vast majority of Terraform users. I wish the change didn’t happen, but it’s only a problem for companies that compete directly with HashiCorp’s managed SaaS offerings.
Pulumi is VC backed, pre-exit, and does not use a FOSS license that prevents it from doing the same thing as HashiCorp when the vultures demand more revenue.
I’ve managed cloud infrastructure at several large tech companies and Terraform scales fine. The declarative and immutable aspects of Terraform are constraints that support scaling. If you’re doing something that feels complicated or hacky in Terraform, you’re often doing something that introduces risk into your infrastructure. It’s good to have pain receptors that warn you of danger.
I think the problem that a lot of companies are grappling with is the specifics. What entails “competing”? I think we all understand the spirit of the text, but how could it be interpreted when new management takes over and decides that want to reap every last penny.
I think people are overcomplicating things.
a) The spirit is critical. Spirit is what a lawyer ends up arguing in court.
b) I suspect that “competing” is relatively well defined. As an example, when you create your company you have to specify its industry - so at minimum I suspect you can trivially argue “we aren’t even in the same industry” and avoid it. If you’re a SaaS/ software company you’ll need another way to differentiate, but again, I don’t think that’s super complicated unless you’re very very close but (just barely) not actually competing.
I think developers think about legal stuff as if it’s code, and they get so hung up on edge cases and specific hangups, but that’s not really legal shit works in my experience (not a lawyer, but I founded and ran a company for years and we had lawyers, I definitely had to think a lot about legal shit).
Any move that takes us further from clarity is a bad one, even if the legal system has norms that allow people to roll the dice and possibly get a good outcome. What you’re basically saying is: it’s ok that you now need to be able to retain a lawyer just in case to try and fight through the ambiguity in complying with the licence terms. That’s pretty rubbish for all the people who legitimately can’t afford one, and even for the people who can it’s a waste of resources. It’s definitely not open source, and people are right to be sceptical and to give it all a wide berth where possible.
As someone pointed out in the past, the problem is acquisitions. What happens if, say, Amazon or Microsoft buys the company? Are you doing anything that competes with any potential purchaser of the company? If so, you are exposed to legal risk.
By this logic, Apple doesn’t compete in the markets for music or, you know, telephones. I’m not a lawyer, but I don’t share your faith that this is a trivial matter at all.
[Comment removed by author]
Good article that makes me want to give Pulumi a try. It touches on the pricing, and I agree with the author that Pulumi moving out of resource-based-pricing could help them take a bigger slice of the market.
Usage-based pricing only makes sense when it aligns your provider incentives with yours. The best example here is logs. To reduce your bill, you’ll chase out noisy debug logs, or sample non-error access logs. You don’t lose a ton of value, and your provider’s operational costs are reduced almost linearly
For IaC, you lose a lot more value (by taking some resources out of the managed state, or re-architecturing your stack to optimize on resource count instead of other factors), while your provider only gets a small saving on runner usage.
The real operational cost of IaC providers is not storing the state, but running the plans and apply. If you cannot bill by user like spacelift does, bill by runner minutes like CI providers do. Then, I can split my stack into smaller chunks to reduce runner usage, and my bill.
Billing on managed resource / hour is ludicrous and a non-starter for me.
Try it. I’ve been pushing Pulumi for a few years and would have converted my current company if they hadn’t already started to adopt Terraform shortly before I joined and before I had earned enough credibility. I haven’t touched it in a couple of years now but being able to write your infra code as code and not HCL unlocks a lot.
Having worked at both HashiCorp and Pulumi (one of six ICs on the Pulumi core team until two months ago), this article is very good, both in its criticisms and comparisons.
Everybody is looking for an alternative to terraform, but it was always there, in Ansible.
As someone who used Ansible heavily for ~5 years: Ansible is pretty awful for cloud orchestration. The modules were of very varying quality, the YAML-based configuration gets old really quickly and in general Ansible is just clunky. One example of that clunkiness is how for certain collections you have to manually install dependencies in the target machine for the tasks to work (the one that comes to mind was Azure, where I had to add an explicit step when setting up the VMs to add specific Python packages otherwise the collection wouldn’t work).
It’s a shame, I really wanted to love Ansible, but after that long working with it, I dreaded every time I had to setup a new kind of server.
My impression from (admittedly light) use of ansible and terraform is that anbsible lacks a lot of the state management terraform has. So for example, when deleting an ASG from a terraform module, terraform is smart enough to delete the ASG. But ansible cannot be because it has no memory of what changes is applied in previous runs.
Having had to fight against terraform state in too many occasions, I think that not having one is an advantage in almost all situations. The only case when the state is helpful is the deletion, as you mentioned, and I only had an handful of those.
Drift detection is extremely useful when you have tens of resources that should be identical (or close enough).
Terraform state doesn’t magically fix it, and sometimes even gets in the way of changes, but without it you can’t even know if the actual configurations changed in relation to the intended state.
I’ve never used these sorts of things at anything more than small scale, but… yes you can? You run ansible with the
--check --diffflags and it prints out the changes it would need to make to bring your systems into the state specified in the playbook. I’m probably misunderstanding what you mean.[Comment removed by author]
What kinds of situations cause you to have to fight with Terraform state? I’ve been using it for years and the only recurring headache I used to have with state was when I wanted to restructure my configuration (moving things into modules, etc.) which used to require an obnoxious amount of manual state fiddling.
But that was before they added the
movedblock to support refactoring. Since I started usingmoved, I can’t remember having to manually mess with a statefile even once.In my experience, which I hope is uncommon,
terraform state rm/pull/pushare commands I ended up typing within 1 week of using terraform.I’ve had issues with:
Manipulating state when moving resources around is perfectly justified in my opinion, but it stems from using state in the first place. If one chooses to interpose a state concept, such as terraform and git, the implementation should be flawless across the entire ecosystem, and from what I’ve seen terraform’s state isn’t.
Data manipulation in Ansible is horrifically painful. Sorry, but these tools just don’t compare.
So many Ansible collections use Terraform under the hood.
Which one? I checked digital ocean, aws, azure, gcp, openstack, online, linode and cloudstack.
All of them used python libraries like boto3, azure sdk or google cloud SDK, … Using terraform sounds counter productive, as they would have to fork-exec on a non-built-in binary, when a lot of the cloud providers provide a python SDK.
Last time I checked, Pulumi used Terraform providers in the background for a lot of resouces (might not be true for the super popular ones like AWS). Is that still the case?
That was the main bummer for me.
It is still the case. Since the providers are under a different license from the core Terraform product, I figured it didn’t matter too much, but yeah if that was a problem for you before it is still there.
but they also have their own providers sometimes
https://www.pulumi.com/blog/pulumiup-native-providers/
That’s only half true .. Lee Briggs explains this well in his misconceptions blog post.
Also, the native providers are implemented completely independently from any hashicorp libraries - they’re created directly from the cloud provider’s specifications. The Azure Native provider is now significantly better than the classic (TF-based) provider. The AWS provider is still in preview due to the new AWS API not yet having support for all the key resource types, but this is already very helpful in certain situations where the classic provider falls short.
I hate doing marketing work, but marketing is everything.
Apparently, Terraform was “good enough ™️” that the author did not spend any time looking for a viable alternative. Fortunately, Pulumi is well positioned to benefit from the HashiCorp license change.
This makes me wonder about Pulumi’s core value proposition: Infrastructure as code in any programming language. No doubt Pulumi has been growing, but I wonder how much market share they were really stealing from Terraform prior to the license change.
I’ve known about Pulumi for years because I read the incredible Midori blog series: https://joeduffyblog.com/2015/11/03/blogging-about-midori/ which led me to Pulumi https://joeduffyblog.com/2019/09/05/journey-to-pulumi-1-0/ :-) I’m not sure if “blog about an experimental OS and programming language” is the best marketing plan overall though.
That’s what AWS CDK does and I really enjoy using it as a result.
https://www.pulumi.com/ai/
This is really cool. I’m a dev, really not super interested in the IAC stuff, definitely not into Terraform (gib code pls). AI is super helpful for stuff like this.
I used Pulumi at my company (Grapl) and it was great tbh
Approximately where does Terraform and Pulumi live on the heptagon of config? And if they can be roughly placed, what are going to expect when moving from one to the other and should we not be surprised when the tradeoffs happen?
idk about Pulumi but in my experience orchestration stuff in general tends to span the “config -> template -> DSL” nodes, with varying levels of emphasis.
Isn’t the difference then that the HCLs repo at least stores expected infrastructure state while the Pulumi API calls are more… ephemeral?