Every time I see this product mentioned, I get a fleeting moment of excitement before I realize that I don't really have any issues with YAML right now. I could probably spend 10 years fixing more important things in my stack versus having my infra in Go or something.
What are the use cases where having this sort of dynamic-ish declaritive-ish hybrid is a solution to an issue that people are having today?
I was able to dynamically issue a key file from GCP IAM with stackdriver access (a JSON file), base64 decode it and pass part of it into an env variable of an AWS Fargate task--- all with Pulumi and all at deploy time. I don't know how I might have done that otherwise, but I can't imagine the alternative would have been as elegant by any other means.
Terraform has been making great strides, but at this point Pulumi really leads in policy, modularity, extensibility via Dynamic providers etc.
I think what they are doing with a K8s provisioner is really interesting. I know that the Kubernetes ecosystem has a dizzying amount of ways to build yaml (and json) config, but Pulumi can reach many other places, all with great type hints.
Here’s a recent example I came across — data is set as a JSON string in an annotation, and the user wanted to use a nested value from that annotation in a later function call. Normally, this type of thing would involve some glue code in a scripting language, but it’s fairly easy to implement as a callback in Pulumi. As someone who had to do a bunch of that prior to Pulumi, I think it’s a great improvement to keep all that logic in the same place. (disclaimer: I work on Kubernetes at Pulumi)
And here’s the Pulumi code snippet in TypeScript required to parse it.
// This defines a callback that runs once the Service is provisioned.
const neg_status = svc.metadata.annotations.apply(x => {
const status = x['cloud.google.com/neg-status'];
const obj = JSON.parse(status);
return obj["network_endpoint_groups"]["443"]
});
// Using the computed value from the callback to dynamically retrieve another value.
const neg = gcp.compute.getNetworkEndpointGroup({
name: neg_status,
zone: "us-east1-d"
});
think about huge CloudFormation yaml files with repetitive logic copy pasted, instead, you can build private subnet with couple of code and assign instances using OOP methods.
I think the apples-to-apples question would be "what's better about this vs. Terraform modules", which is IME the most common approach to composition of infrastructure-as-code right now.
Terraform modules are definitely a bit rough in places, for example having to define `variables` and `outputs` at each layer of composition.
But on the flip-side, spelunking into TF modules is really easy when you want to figure out what's going on (I can usually make sense of the module from reading the Git repo), and I've found the Pulumi intermediate representation to be significantly harder to grok (especially if you're pointing Pulumi at a Terraform module that they have translated to TypeScript...)
It covers many types of infrastructure outside of K8s. In the sense that you can use it to templatize infrastructure and inject many configs, it can work like helm. You can also use it in many other ways as well- creating your own classes, helper libraries, ternary operators, and all of the comforts of a general purpose language (often with a debugger).
Pulumi can deploy existing helm charts- just create a Helm resource, tell it where to look for the helm file, and it will deploy it and own its state moving forward.
What are the use cases where having this sort of dynamic-ish declaritive-ish hybrid is a solution to an issue that people are having today?
Terraform has been making great strides, but at this point Pulumi really leads in policy, modularity, extensibility via Dynamic providers etc.
I think what they are doing with a K8s provisioner is really interesting. I know that the Kubernetes ecosystem has a dizzying amount of ways to build yaml (and json) config, but Pulumi can reach many other places, all with great type hints.
Here’s the annotation:
And here’s the Pulumi code snippet in TypeScript required to parse it.Terraform modules are definitely a bit rough in places, for example having to define `variables` and `outputs` at each layer of composition.
But on the flip-side, spelunking into TF modules is really easy when you want to figure out what's going on (I can usually make sense of the module from reading the Git repo), and I've found the Pulumi intermediate representation to be significantly harder to grok (especially if you're pointing Pulumi at a Terraform module that they have translated to TypeScript...)
Pulumi can deploy existing helm charts- just create a Helm resource, tell it where to look for the helm file, and it will deploy it and own its state moving forward.