Consider introducing a cloud.Function abstraction

i.e. instead of having APIs like:

export declare function cron(name: string, cronTab: string, handler: Action): void;

we would have:

export declare function cron(name: string, cronTab: string, handler: cloud.Function): void;

users would then invoke this by doing:

cloud.timer.cron(..., new cloud.Function({ function: async () => {
      // code to run in aws lambda, or azure function
}});

Pros:

1. Clearer separation between code that runs at deploy time, and the code we want to eventually run at runtime. Aka: self-documenting.
2. Stronger ability to catch certain types of issues at pulumi/lint time. (i.e. we could lexically catch users making resources inside of these cloud functions). It would likely not be foolproof. But would help catch a broad set of errors.
3. Closer programming model to what we have with tasks. i.e. today you do cloud.timer.cron(..., new cloud.Task(..., { function: ... ] ]). Now the programming model for functions running in Lambdas vs Containers is more similar.
4. Better for teaching/explaining what is going on. Today, our examples are so simple that it just looks like a basic app that runs and doesn’t do anything special. With this split it becomes more obvious “ohhhh, all these functions are running as separate lambdas… but, omg, they all get to party on this ‘table’, which just looks like a variable in source”.
5. Easier to configure lambdas in the case users need to. for example new cloud.Function( { memory: 256, function: () => { ... } }). (see https://github.com/pulumi/pulumi-cloud/issues/121)

Cons:

1. verbosity. Though my gut tells me it would be isolated. I think it would help people better structure their code to decide what would be partitioned into a particular lambda.
2. Superfluousness. As our existing programming model demonstrates, we don’t actually need this. There are also existence proofs for similar systems that also avoid this sort of explicit separation in code. For example, lambdas in C# are either delegates, or become Expression trees. If i write table.Where(c => ... ) what i get is completely dependent on the types of the variables involved, and may not be clear just from perusing the code. This may be a good or bad thing depending on who you talk to 😃
3. Less “magical”. But maybe there are enough good things about this that that’s acceptable.

[joeduffy]

Agree 👍. I put in M9 because I’d like to see us do this “soon”. IMHO, one of the highest priority things to do in our cloud framework backlog, given the widescale impacts.

/cc @CyrusNajmabadi

[CyrusNajmabadi]

Closing as #573 is covering this now.