5 ms·
It's infrastructure-as-code to the logical conclusion that you write real programming language code (Python, Javascript, Go, etc.) to build your infrastructure.
by qbasic_forever 6y ago
It's infrastructure-as-code to the logical conclusion that you write real programming language code (Python, Javascript, Go, etc.) to build your infrastructure. Something like Terraform lets you declare infrastructure with HCL/JSON but doesn't give you a lot of flexibility to reason about or dynamically change things. If you want to spin up a frontend server for every backend for example, you have to write out the configs and tweak them to match the desired state. Pulumi and similar tools go the next step and let you write code to build your infrastructure--if you want your frontends and backends to be in sync, write some Python to make it happen instead of spelunking in a pile of configs.
It's super useful and compelling at scale, but there are some potential downsides. For one, it's a real program and IMHO you should treat it as such with the same rigor of documentation, testing, etc. as the production code you're deploying. This might actually make your processes a bit slower or more risky. Because if you don't do that then you just risk building unmaintainable, untrustworthy deployment code that nobody wants to use.
The second downside is you're taking a big bet on Pulumi to stick around. At this point, it's probably a safe bet. But the more you use their SDK and system the more tightly coupled your production deployment is to the continued existence of Pulumi. If they go bust and can't maintain the SDK you might have a production system that can't be deployed anymore.
- jacobmischka 6y agoThank you for this concise summary. While not a dedicated cloud services administrator, I keep up with new technologies and follow tech news fairly religiously, and this press release made my head hurt with all of the cloud-specific buzzwords and proper nouns. Sounds like a neat and useful project for complex setups.
- qbasic_forever 6y agoYeah there's a lot of churn going on, but the infrastructure space is innovating in really interesting ways right now. On one side you have things like Pulumi diving into the full programming language for configs, on the other side you have an entirely different ethos of git-ops where you only have 'dumb' JSON/YAML configs and store all their state in a git repo with hooks to deploy and manage everything--(ArgoCD, flux, etc. are tools here). And in the middle you have some ideas for non-turing complete languages like Starlark, Jsonnet, Cue, Dhall, etc. to let you do some config generation but limit the risk of building broken configs. There's really no definitive 'winner' or best option yet. Each has strengths and weaknesses relative to others. It might just come down to how a team prefers to manage and work with infrastructure.
- majestik 6y agoThere’s nothing preventing you from using Pulumi with GitOps, in fact it’s an encouraged pattern.
- deleted 6y ago[deleted]
- aetherspawn 6y agoThanks, I wanted to know the main difference between Terraform and this (ie why would I pay $50/mo), but this sums it up nicely. Still, Terraform has my needs at this stage and looks a lot more mature. But if I was a small web host or something this could be a really interesting integration.
- ludwigvan 6y agoI think they don't advertise it that prominently for marketing reasons, but note that you don't have to pay unless you use Pulumi SaaS (the web ui). In that case, you can save your state in an S3 bucket, just like you save your Terraform state somewhere.