What is the status of this vs. AWSLambdaPSCore?

[yobyot]

I am confused by the existence of this project.

Is it a replacement for AWSLambdaPSCore? If so, why isn't this project formally documented in the AWS documentation as an alternative to that? The doc, AFAIK, still refers only to AWSLambdaPSCore.

A blog post from 2022 and a seven-minute demo YouTube video are insufficient to determine the production viability of this project for pwsh devs want the durability and production support of AWSLambdaPSCore. Is AWS recommending new functions developed in PowerShell should be deployed using this technique? Is there a deprecation date for AWSLambdaPSCore?

These questions, and many more that devs need to assess the production quality and future of this project are unanswered.

Also, I'm not sure that the benefits of editing code in the AWS console outweigh the clumsy (and poorly documented) deployment process and added size. I'd appreciate knowing why running in a container with a layer of indeterminate durability is better than bundling a supported .Net runtime with known, specific versions of AWS.Tools modules.

Clearly, I don't "get it." :-)

[julianwood]

Hi, this isn't a replacement for AWSLambdaPSCore and there is currently no deprecation date planned for AWSLambdaPSCore. It is an alternative for people who want to run a pure PowerShell runtime who may not be used to working in .NET. We are looking to have this included in the AWS documentation as an option.

We heard from PowerShell customers who found the .NET based compilation experience complex and didn't understand what New-AWSPowerShellLambdaPackage actually does.

An example is an IT automation PowerShell user who knows enough about Lambda to run a function and wants to run some scheduled tasks. They can create a Lambda function in the console, or via IaC and select the custom runtime. By adding a PowerShell Lambda Layer and potentially additional cmdlets via their code/another layer, they can build their automation scripts without having to use Lambda specific PowerShell packaging and deployment tools. These users like the console edit experience.

Advanced users like that they can share the PowerShell runtime layer between multiple functions, which makes it easier to update PowerShell versions.

As for the added size, yes, this is one of the trade-offs. Being specific about the modules required (as people do with the AWSLambdaPSCore version) reduces the package size.

For larger package sizes, building a container image is a solution. AWSLambdaPSCore doesn't cater for this so this runtime provides a container image creation process where you can more easily see how the components are packaged, without having to compile .NET.

As for the production quality and future, we have a number of individuals within AWS who curate this project and it is used internally. The OS runtime is fully supported and maintained by AWS. The PowerShell part is native PowerShell and open source, so you can see exactly how it works.

We are always looking for feedback to improve the experience. How can we improve the deployment process and documentation?

[yobyot]

Thanks for the detailed, throughtful reply, @julianwood.

Personally, and since I've been using it for years, I don't find New-AWSPowerShellLambdaPackage all that difficult to use. And I'm hardly what one would call a .Net dev. Maybe it's familiarity -- I've been using it since 2018. Functions created using this process run reliably and are supported.

And relates to my real concern: is this project a project or a product? If it's the latter, it needs to be "official," whatever that means in AWS. (I have no idea what your internal product management process is so I can't offer any suggestions on that point.)

In the enterprise world where I work, if it's not in the documentation and AWS Support doesn't provide support for it, it's not something I can recommend to or implement for clients. It's not enough to say to a defense contractor, "One of the Github contributors says that lots of people inside AWS use this."

You ask how to improve the experience and doc? Offer it as a formal alternative, documented here. List all the requirements, work on multiple examples and tutorials and, if possible, eliminate the requirement for SAM.

Thanks again.

[sean-r-williams]

We are looking to have this included in the AWS documentation as an option.

@julianwood, has your team made progress in this area?

My team is onboarding to Lambda for the first time with a PowerShell codebase we've developed. Comparing the feature-set of this runtime against what's supported by the .NET runtime has been very difficult.

I filed an AWS support case (172081530100577) to ask for specifics - AWS support was able to answer some of my questions after some iteration, but the level of feature-comparison I was looking for shouldn't have needed a support ticket IMO.

Given the relatively small intersectional niche of "PowerShell" x "AWS Lambda", trying to piece together coherent guidance between AWS docs, this repo, community members' repos, and so on has been very difficult.

It would be very helpful if AWS support - both written docs and human support agents - had enough context on the .NET/PowerShell custom runtimes to present a reasonably comprehensive comparison between the two. As a new user of Lambda (coming from Azure Automation &co), getting started has been really difficult.