Lambda and other thoughts

• Allow the user to declare assembly dependencies. (what UX?)

  • e.g. A function depends on a custom assembly, which will be loaded by using Assembly ... or Add-Type ..., or Assembly.Load(...). Do we want to support that scenario? One solution would be the AssemblyLoadContext.Default.Resolving.

• ~Capture Write-Host to logging~ Write-Host also write the message to Information stream, so we are good here.

• PowerShell based Lambda doesn’t bundle AWSPowerShell.NetCore (AWS version of AzureRM.NetCore) with the runtime, but instead, bundle it with user’s scripts in the deployment package. The user needs to use #Requires -Modules in script to specify the module dependency.

  • I don’t like having AzureRM.NetCore bundle with user’s Function App, that will likely cause duplications of such module, which is a waste of bandwidth. However, that would solve the module version issue, since user needs to be explicit about what version of AzRM to be deployed.
  • But we do need a way to let user specify what custom module they want to deploy along with their scripts. (what UX? use #Requires -Modules like Lambda does?)
  • Just realized that the func CLI doesn’t have a pack option. Is the deployment restricted to container image? dotnet-lambda package pack the function app into a zip file, ready for deployment.
    • Lambda provides a powershell module to facilitate creating a powershell lambda, including templates, create a package (zip), publish a package to AWS.
    • By having a powershell helper module, it’s able to parse the script to get the module dependencies from #Requires -Modules ..., and pack the dependencies into the package. We cannot find the dependency moduels without running in the PowerShell session that the user uses for creating the function.

• ~Lambda tool is a .NET Global Tool “Amazon.Lambda.Tools”. Maybe func CLI should consider to be a Global Tool too, given it’s a .NET Core application.~ (not related to the PS worker)

[daxian-dbw]

Thanks @KirkMunro for sharing your experiences. For the last two points, it’s doable by loading a module to a separate AssemblyLoadContext. Both code and data (statics) from a module can be isolated in that way. The idea is to add a new flag -Isolated to Import-Module to explicitly make powershell load a module to a separate assembly context. The tricky part is how the type resolution in powershell should change accordingly. I will write up an RFC on this after PSConf Asia, probably in late November.

[SteveL-MSFT]

func CLI as a global tool makes sense but is orthogonal to this and I suspect many PowerShell scripters won’t have dotnetcli installed.

From a packaging standpoint, I think it would be interesting to have a generic way to package a script and dependencies so that ITPros can easily distribute them in their environment even outside of AzF. This can simply be a zip with a well known extension and layout (including assemblies).

I like the idea of requiring the user to package Az module rather than having it in our worker image to resolve the versioning problem.