Thanks -- we're very excited to be out and talking to the community!
> What is difference in the use case for Pulumi compared to scripting infrastructure using vendor provided libraries
The major difference is that Pulumi does immutable infrastructure. The code describes a goal state and our system manages your environment to ensure that it matches the goal state. This means you can preview changes before making them, and that, if you do make them, you've got a full audit trail of who changed what and when. Rollbacks are trivial because you just point us at an old goal state worked and we can chew on it until your live environment matches. We can even detect drift, so if someone manually updates in the cloud console, we can tell you about it. As a result, we always have a full object graph of your cloud resources, and can tie it back to the source code which created it, opening up some unique diagnostics capabilities.
The difference with scripting libraries, like AWS's Boto, or the Azure PowerShell SDK, is that they mutate cloud resources directly, and in an ad-hoc manner. So, you don't know what they are going to do before you run them. And in the event of failure, you're more likely to be in a corrupt state and unable to recover. Rollbacks are difficult. There's also no audit trail beyond the cloud access logs, and information like dependencies are lost, so resources end up disassociated from the code and workflow that created or updated them. Many people encounter these problems and need to build complex systems on top to address them. Or they end up using a solution like CloudFormation or Azure Resource Manager, which eschews code in favor of JSON/YAML/templates.
The hope here is that we've landed on a sweet spot between immutable infrastructure and fully programmable languages.
Thanks -- we're very excited to be out and talking to the community!
> What is difference in the use case for Pulumi compared to scripting infrastructure using vendor provided libraries
The major difference is that Pulumi does immutable infrastructure. The code describes a goal state and our system manages your environment to ensure that it matches the goal state. This means you can preview changes before making them, and that, if you do make them, you've got a full audit trail of who changed what and when. Rollbacks are trivial because you just point us at an old goal state worked and we can chew on it until your live environment matches. We can even detect drift, so if someone manually updates in the cloud console, we can tell you about it. As a result, we always have a full object graph of your cloud resources, and can tie it back to the source code which created it, opening up some unique diagnostics capabilities.
The difference with scripting libraries, like AWS's Boto, or the Azure PowerShell SDK, is that they mutate cloud resources directly, and in an ad-hoc manner. So, you don't know what they are going to do before you run them. And in the event of failure, you're more likely to be in a corrupt state and unable to recover. Rollbacks are difficult. There's also no audit trail beyond the cloud access logs, and information like dependencies are lost, so resources end up disassociated from the code and workflow that created or updated them. Many people encounter these problems and need to build complex systems on top to address them. Or they end up using a solution like CloudFormation or Azure Resource Manager, which eschews code in favor of JSON/YAML/templates.
The hope here is that we've landed on a sweet spot between immutable infrastructure and fully programmable languages.