Comment by joeduffy | Hacker News Reader

Comment by joeduffy | Hacker News Reader

Parent Full thread

You're right, the Pulumi example is a project, not a reusable module. There are a few approaches to making it modular:

1) The project does support config. So if you want to change (e.g.) the number of AZs, you can say

    $ pulumi config set numberOfAvailabilityZones 3
    $ pulumi up

And Pulumi will compare the current infrastructure with the new goal state, show you the diff, and then let you deploy the minimal set of changes to bring the actual state in line with the new goal state. This works very much like Terraform, CloudFormation, Kubernetes, etc.

2) You can make this into a library using standard language techniques like classes, functions, and packages. These can use a combination of configuration as well as parameterization. If you wrote it in Python, you can publish it on PyPI, or JavaScript on NPM, or Go on GitHub -- or something like JFrog Artifactory for any of them. This makes it easy to share it with the community or within your team.

3) We offer some libraries of our own, like this one: https://github.com/pulumi/pulumi-awsx/tree/master/nodejs/aws.... That includes an abstraction that's a lot like the Terraform module you've shown, and cuts down even further on LOC to spin up a properly configured VPC.

I am a big Go fan too, so I very much know what you're saying. (In fact, we implemented Pulumi in Go.) Even with Go, though, you've got funcs, structs, loops, and solid basics. Simply having those goes a long way -- as well as great supporting tools -- and you definitely do not need to go overboard with abstraction to get a ton of benefit right out of the gate.

Again, I'm biased and YMMV :-)

"The project does support config. So if you want to change (e.g.) the number of AZs, you can say..."

Cool, is it possible to do that without having to use the CLI? Are you doing any sort of state locking here? I've seen ops teams get saved from potentially horrible situations by Terraform's dynamodb state locking.

"You can make this into a library using standard language techniques like classes, functions, and packages."

That's pretty nice and it seems like it'll get you the same functionality as a Terraform module. Do you have any plans of releasing something like the Terraform Registry to help with discoverability?

Also, do you have any docs on writing providers? I've had to do that a few times for Terraform and getting up and running with that was pretty easy as a Go developer. I wouldn't really want to do that for every supported language though (no offense C#).

I'm seeing that some of this is using codegen to read the equivalent Terraform provider and generate the Pulumi provider from that schema. Is that the preferred workflow here for providers that already exist in the Terraform ecosystem?

> is it possible to do that without having to use the CLI? Are you doing any sort of state locking here?

Yeah it's just a file if you prefer to edit it. By default, Pulumi uses our hosted service so you don't need to think about state or locking. That said, if you don't want to use that, you can manage state on your own[1]. At this time, you also need to come up with a locking strategy. Most of our end users pick the hosted service -- it's just super easy to get going with.

> Do you have any plans of releasing something like the Terraform Registry to help with discoverability?

I expect us to do that eventually, absolutely. For us it'll be more of an "index" of other package managers since you already have NPM and PyPI, etc. But definitely get that it's helpful to find all of this in one place -- as well as knowing which ones we bless and support.

> Also, do you have any docs on writing providers?

We have boilerplate repos that help you get started:

1) Native providers: https://github.com/pulumi/pulumi-provider-boilerplate

2) Terraform-based providers: https://github.com/pulumi/pulumi-tf-provider-boilerplate

These packages are inherently multi-language and our code-generator library will generate the various JavaScript, Python, Go, C#, etc, client libraries after you've authored the central Go-based provider schema.

> Is that the preferred workflow here for providers that already exist in the Terraform ecosystem?

Yes. We already have a few dozen published (check the https://github.com/pulumi org when in question). In general, we will support any Terraform-backed provider, so if you have one that's missing that you'd like help with, just let us know. We have a Slack[2] where the team hangs out if you want to chat with us or the community.

[1] https://www.pulumi.com/docs/intro/concepts/state/#self-manag...

[2] https://slack.pulumi.com

Reply on news.ycombinator.com