3 ms·

Pulumi does basically the exact same thing as terraform but in the language of your choice. We started using it in our company because we noticed that terrafor

Pulumi does basically the exact same thing as terraform but in the language of your choice. We started using it in our company because we noticed that terraform as a separate language was enough of a barrier that it prevented a good deal of our developers from contributing to the infrastructure codebase, creating a separation between 'devs' and 'devops' guys. We switched to Pulumi for a new project, and now basically everybody is contributing to the infrastructure. Which completely changed the dynamic of development for the better. Frankly for us it's been a gamechanger.

thenaturalist 4y ago
As someone who started out not as a Devops/ Cloud Engineer person but got into TF: Would you mind sharing more specifically how Pulumi has changed the game for you with lowering the barrier to "do infra"? I am curious because everytime I considered using it so far, the prospect of just any dev who might well not know all the intricacies of infra should maybe not build it. I guess some barrier to entry is something I would see as a benefit. In terms of code syntax, reading infra declarations in app languages always rubbed me the wrong way. Yes, HCL is no beauty and a bit to get into, but after that, I personally love it. I know exactly what to look for. The thought of reading this in all kinds of Python syntax is rather a downer for me. Last but not least, there is a ton of tooling which was built around TF which I am not aware of if equivalents do exist for Pulumi. Fwiw, I have no skin in the game of either company and am not trying to paint a black or white picture of what's the better tech. Just trying to learn what appeals to others about Pulumi.
- fvdessen 4y ago
  > I am curious because everytime I considered using it so far, the prospect of just any dev who might well not know all the intricacies of infra should maybe not build it. I guess some barrier to entry is something I would see as a benefit. First, your dev process should go through a review phase robust enough that beginners should be able to develop on things they are unfamiliar with confidence. Second, the infra being 'intricate', needing huge tooling etc, is a sign that it has become too complex; maybe because it is not well aligned with the application side, maybe because the 'devops' have been making an infra monolith, or maybe because it is making use of too low level features. For example we're on GCP, and we're making use of serverless tech such as cloud run, functions, cloud sql, pubsub, IAM, etc. Those are all high level building blocks that are very easy to configure & deploy using pulumi. Since the devs can for example add a cloud function for a feature & go to prod entirely on their own with just one language, they make use of it, so we get better architecture as a result. In a sense the cloud platform itself becomes the full stack framework. The cloud platform provided blocks also enforce good practice so it's harder for newcomers to shoot themselves in the foot. If we were using native k8s, self managed postgres etc, then it would probably not work as well. But yes, pulumi is less mature & we're hitting some bugs here & there, and we're completely locked into a cloud provider. But the upsides are impressive & IMHO worth it. I used to be a proponent of monoliths for dev speed, but now I've seen that you can match the prototyping speed with microservice/serverless & get a much better solution as a result.
- mountainriver 4y ago
  Worth noting that Pulumi can convert to TF if you have an integration you really need. Infrastructure definitions are complex, general purpose languages are built for this kind of stuff

thenaturalist 4y ago

As someone who started out not as a Devops/ Cloud Engineer person but got into TF: Would you mind sharing more specifically how Pulumi has changed the game for you with lowering the barrier to "do infra"? I am curious because everytime I considered using it so far, the prospect of just any dev who might well not know all the intricacies of infra should maybe not build it. I guess some barrier to entry is something I would see as a benefit. In terms of code syntax, reading infra declarations in app languages always rubbed me the wrong way. Yes, HCL is no beauty and a bit to get into, but after that, I personally love it. I know exactly what to look for. The thought of reading this in all kinds of Python syntax is rather a downer for me. Last but not least, there is a ton of tooling which was built around TF which I am not aware of if equivalents do exist for Pulumi. Fwiw, I have no skin in the game of either company and am not trying to paint a black or white picture of what's the better tech. Just trying to learn what appeals to others about Pulumi.

fvdessen 4y ago
> I am curious because everytime I considered using it so far, the prospect of just any dev who might well not know all the intricacies of infra should maybe not build it. I guess some barrier to entry is something I would see as a benefit. First, your dev process should go through a review phase robust enough that beginners should be able to develop on things they are unfamiliar with confidence. Second, the infra being 'intricate', needing huge tooling etc, is a sign that it has become too complex; maybe because it is not well aligned with the application side, maybe because the 'devops' have been making an infra monolith, or maybe because it is making use of too low level features. For example we're on GCP, and we're making use of serverless tech such as cloud run, functions, cloud sql, pubsub, IAM, etc. Those are all high level building blocks that are very easy to configure & deploy using pulumi. Since the devs can for example add a cloud function for a feature & go to prod entirely on their own with just one language, they make use of it, so we get better architecture as a result. In a sense the cloud platform itself becomes the full stack framework. The cloud platform provided blocks also enforce good practice so it's harder for newcomers to shoot themselves in the foot. If we were using native k8s, self managed postgres etc, then it would probably not work as well. But yes, pulumi is less mature & we're hitting some bugs here & there, and we're completely locked into a cloud provider. But the upsides are impressive & IMHO worth it. I used to be a proponent of monoliths for dev speed, but now I've seen that you can match the prototyping speed with microservice/serverless & get a much better solution as a result.
mountainriver 4y ago
Worth noting that Pulumi can convert to TF if you have an integration you really need. Infrastructure definitions are complex, general purpose languages are built for this kind of stuff