This message was deleted.

Pulumi is declarative, you say "these are the resources I want with these properties and relationships." Pulumi handles how to call the SDKs via the providers. If you're using the SDKs directly, it's your responsibility, a lot more logic, upkeep and edge cases.

@millions-furniture-75402 OK thanks, few questions, 1. regard the code in case I want to create an IP or natGW , is the code is similar for different iaas or this is different (reference will be helpful) and pulumi does the abstraction over the diff IAAS code 2. Does Pulumi support get . for example I've created a resource and I want to get the data after creation ?

1. Currently they will be provider specific, though Pulumi is working on a "cloud" API that abstracts common resources across providers 2. Yes, you can .get() a resource, (it doesn't even have to have been created by Pulumi)

@millions-furniture-75402 - thanks, you said

Pulumi is declarative, you say "these are the resources I want with these properties and relationships." Pulumi handles how to call the SDKs via the providers.

does it mean that to achive the same with Pulumi i'll use less code ? (compere to iaas sdk)

As the complexity of the resources you're declaring increase, so would your custom code. With declarative infrastructure, that complexity is largely handled by the providers. The benefit to using Pulumi is that you get the benefits of a declarative pattern within a general purpose programming language. So instead of some whacky way to handle logic, loops and conditionals, like you might with Terraform's HCL language, you can use it in a clearer way, and take advantage of that language's ecosystem. This includes if you need to mix using the cloud provider SDKs directly for some resource.

So instead of some whacky way to handle logic, loops and conditionals, like you might with Terraform's HCL

This, but not only this. Pulumi allows you to create any abstraction that makes sense for your use-case since you have the full power of a general purpose language. Terraform's HCL does not allow this. This is a totally nontrivial difference when it comes to both writing new infra code and maintaining existing infra code.

As an example, developers could be installing node packages maintained by Operations and Security teams. The developers don't know how know all the details about deploying and hardening their application, but can use components managed by other teams that are distributed as libraries with API interfaces and tooling that developers are already familiar with.

@millions-furniture-75402 @steep-toddler-94095 - it would be great if you can provide some example/ref for that, I need to convince my team also 🙂

I don't know of any examples off-hand. I cannot share my organization's examples unfortunately. You might find this page helpful: https://www.pulumi.com/docs/guides/pulumi-packages/