Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Converting Full Terraform Programs to Pulumi

pulumi.com

Post reply on HN
Print view View original

61–66 of 66 posts

Re: Converting Full Terraform Programs to Pulumi

#61

Post by el-duderino42 »

sureglymop wrote: post #58
el-duderino42 wrote: post #40

If devs write and maintain their own IAC then Pulumi is a good choice since they can write it in a familiar language. If however a dedicated devops team has to manage it eventually, and there are multiple dev teams who all use different languages, then Terraform is better, since it’s practically impossible to learn all these languages. Terraform will give you a dumbed down enough lingua franca. Also Terraform gives y…

Can Terraform be used in place of ansible? I've seen way to much "logic" in ansible playbooks.

Lol exactly - “logic”

Terraform can’t replace it well. Maybe facilitate the transition to more cloud native setups where you don’t need Ansible at all. But only within limits. If you’re asked to implement something there’s no cloud offering for, and it’s slightly more complex, you’re back to ansible.

Re: Converting Full Terraform Programs to Pulumi

#63

Post by lukehoban »

silasdavis wrote: post #36
Volundr wrote: post #24

Earlier quoted context omitted.

Sort of. You can use Pulumi for free as an individual. As a team you'd have to use a backend for your state other than Pulumi cloud, and your responsible for your own concurrency control [1]. In a team environment that's such a big foot gun I don't really consider it usable. That limitation makes Pulumi a nonstarter for me. Even if I am paying for it, this is super sensitive data and I want control over how it's stor…

I've not pushed the concurrency at all but I think it creates a lock file in storage which gives basic concurrency management. The self hosted backend does have plenty of wringles though like not supporting the same stack name across different projects with the same backend URL contrary to how the hosted backend works. Nonetheless it has been perfectly usable for us without paying for their hosting.

> The self hosted backend does have plenty of wringles though like not supporting the same stack name across different projects with the same backend URL contrary to how the hosted backend works.

Just a note that we did add support for projects to the self-hosted backend a few months ago, which does bring the self-hosted and managed backends into alignment here.

https://www.pulumi.com/blog/project-scoped-stacks-in-self-ma...

Re: Converting Full Terraform Programs to Pulumi

#64

Post by irjustin »

danielbarla wrote: post #52
irjustin wrote: post #21

Honest question, if you're locked in to AWS why not just use the CDK? I've used Terraform and Pulumi in the past and the "platform agnostic" is only true for trivial builds. Once you get into medium sized infra you're writing so much AWS specific code it stands better to go 1st party. I can't speak for GCP, but this is what happened to us. We kept fighting 3rd party code we ended up going CDK. While there are still i…

I absolutely love the CDK's typed approach. Having said that, I still would choose Terraform over CDK mainly because of the way they handle drift detection / drift resolution. Basically, with CDK and the underlying CloudFormation, you can get told that there's a drift. And that's it; now you have to go and fix it manually. Someone deleted half your infra? Well, have fun rebuilding it by hand. With terraform, you just…

> And that's it; now you have to go and fix it manually

This is very true. We didn't get far enough to get into a drift issue to compare CDK vs 3rd party, so this is new to me, thanks for that. Admittedly, we solved this by saying no one is allowed to click buttons at all on the console for certain envs.

What's worked well for us is we multiple sub-accounts which handle dev(s), stage, uat, prod. Dev(s) accounts are pure temp, use the CDK to stand it up, then click all you want while you "figure it out".

Stage, UAT, and Prod are all code only.

We also separate Network vs Application stacks, but it's more actually delete-able vs critical. Dangerous to delete/mess with - Route53, RDS, VPC, S3 (some). Delete-able is Lambda, EC2, ElastiCache, etc. If we lost these, we don't "lose" anything other than downtime no backups/cust data gone and restoring it is trivial.

Also agreed on the experimental packages or needing to use the escape hatches. We have L1, L2 mixed all over the place. We use almost no L3 because it's like Hello World - great for demos but not really practical and it's easier to customize the L2's because getting access to individual resources in L3 is janky (but we do do it for a few L2's).

Re: Converting Full Terraform Programs to Pulumi

#65

Post by sureglymop »

el-duderino42 wrote: post #61
sureglymop wrote: post #58

Earlier quoted context omitted.

Can Terraform be used in place of ansible? I've seen way to much "logic" in ansible playbooks.

Lol exactly - “logic” Terraform can’t replace it well. Maybe facilitate the transition to more cloud native setups where you don’t need Ansible at all. But only within limits. If you’re asked to implement something there’s no cloud offering for, and it’s slightly more complex, you’re back to ansible.

I can't do clouds except if the cloud itself is self-hosted. I'm always working with minimal hypervisors based on something like kvm/libvirt. Then I can do all the cloud stuff on top of that and boot vms with cloud-init. But over time a lot of ansible playbooks have accumulated and ideally I would like the entire state of all the infrastructure to be in a git repository. It's possible with ansible but I think it'll break in no time ;(

Re: Converting Full Terraform Programs to Pulumi

#66

Post by cube2222 »

tjasdfhwd___ wrote: post #4

I've been happy with Hashicorp Terraform Cloud and HCL except for the very recent price hikes which may force us to leave them so we are keeping our eyes out for alternatives. The AI assistant seen here is a very good idea. I will actually share this with my team. I imagine the terraform conversion doesn't work when you use in-house written providers (in golang), is this correct?

Hey!

I recommend checking out Spacelift[0]. It's a CI/CD system specialized for Infra as Code, including Terraform and Pulumi. We have both a ton of additional features, as well as a much more reasonable pricing model, so we've recently been talking a lot to folks wanting to migrate from TFC due to the changes you've mentioned.

You can easily reach out to us on the website by scheduling a demo, using the chat widget, or just sending me an email (see my profile).

[0]: https://spacelift.io

Disclaimer: Software Engineering Team Lead at Spacelift, so take this with a healthy grain of salt, but I do legitimately think it's a great product.

Post reply on HN