The

@pulumi/cloud

library in particular is designed to be high-level abstractions which could be created on multiple different cloud platforms. But that's just one kind of library that can be built. Things like

@pulumi/aws-serverlesss

and

@pulumi/aws-infra

provide helpful higher level abstractions that are still specific to AWS but making common patterns much easier to use.

So I guess the scripts know which cloud they are running on and branch based on the cloud?

That's right - there is a

cloud:provider

config variable which can be set to decide which provider it will target. This is ultimately not entirely unlike deciding which

aws:region

you want to target - but just an even bigger switch. See https://github.com/pulumi/pulumi-cloud/blob/master/api/index.ts#L31 for the details.

I also think of them as simpler abstractions to use, and not just LCD. Think .NET filesystem APIs versus Win32. Sure sometimes you need

kernel32!CreateFile

and

FILE_FLAG_OPEN_REPARSE_POINT

and so on, but usually

File.Open

does the job just fine. Just as in .NET, where you have P/invoke, in those cases where the high level primitives don't work, you can always drop down to the lower level cloud-specific APIs, even mixing them in the same program.

Yeah, totally. Seems like it could be awesome.

Hi Eric, for using NPM packages do you mean like adding postgres/ES clients or the servers themselves?

For packages that make it easy for app developers to use those things in their stack.