just because I don't get it from their marketing: their API is a cloud-service wrapping other cloudservices. Or is it a classical library with wrappers?
Suppose you wrote a program to go and create your cloud infrastructure. Using AWS’ APIs you write an app to spin up a VM, setup a load balancer, and provision a database. You run your program, it works like a charm. Now you have all the infrastructure setup just the way you want it!
The problem is what happens when you want to _update_ that infrastructure? The program you wrote, using the aws.CreateVM(..) and aws.CreateLoadBalancer(..) API calls is no longer applicable. Instead, you probably want to use a different set of APIs, like aws.UpdateVM(…), to update your existing cloud resources. For example, change some port settings on your load balancer. So your app needs to be smart enough to check if the resources already exist, and if so, update them. Otherwise, create them fresh.
And it gets even worse. What if you want to create some new resources, such as attach an SSL certificate to your load balancer… but still keep all of your existing infrastructure as-is. Or what if you want to update an IAM usage policy that is already in-use by several other resources… Somehow your app needs to know the impact of that change, and how it will ripple out across other cloud resources.
Does that start to make sense? You don’t really want a “wrapper” for cloud APIs. You really want something that allows you to effectively describe your cloud infrastructure, and “make it happen”. And leave the specifics of “how” as an implementation detail… accomplished by a cloud provider’s APIs.
That is what Pulumi does — and other Infrastructure as Code tools, like Terraform. It provides you a way to describe your cloud infrastructure in a programming language, so that every time you run your app it will make the cloud reflect that target state. It will:
- Create resources if they don’t exist. - Update existing resources if they do. - Delete any resources that you no longer need.
I work at Pulumi and am happy to go into details about the joys of not dealing with cloud APIs directly, and just using Pulumi :)
And in addition to making it easier to manage cloud resources by defining that state in a programming language, Pulumi can do other interesting things with your resource graph too. For example, analyze resources and check that they are compliant with security best practices and what not. https://www.pulumi.com/docs/get-started/crossguard/
With it, you can bring up some infrastructure on machine A and tear it down on another machine.
Without the service, you can only tear down on the same machine you brought it up. Ditto for adding to existing infrastructure.
You don't need their service but you have to solve problems like knowing what is running, replicating the needed state etc.
The service is very nice and makes it easy to know what is running, how long it has been running, who created it etc- across clouds. But, it is not strictly needed. As an individual user, you could get away without using. For a team, it fills a very vital gap.