Reprioritizing PowerShell support in the Azure Functions runtime #585
Comments
|
+1 |
|
+1 100% |
|
Overall, we're fairly confident that once we move to modules, we'll have a scalable model that doesn't require file I/O for each execution. Advanced data types isn't a requirement for us to support a language - we made that decision explicitly. We definitely apologize for any lack of transparency. We're currently trying to wrap up the language extensiblility functionality we've been building (Node.js and Java as the guinea pigs). We've not prioritized adding the other languages back in, quite yet, since there's still a bit of work left to make easier to test/support new languages (today, every change to our gRPC contract is 3-4 PRs 😒). There's a general roadmap here: Azure/azure-functions-host#1964. We are starting to get the other language experts engaged to begin design for other languages. We're hoping we can get the PowerShell team themselves to help us make sure it's great (where we hacked the first one together ourselves...).
These types of issues do help 👍. We need to know there's excitement (though usage numbers alone are good enough for us, tbh) and we want to be able to show the PowerShell team there is a folks from their community that are eager, as well. It would be great to keep getting examples of what you're using (or want to use) PowerShell for in Azure Functions. It would also be great to get any feature suggestions we can include in our design discussions. To start that off, let me ask: If we stayed on PowerShell 4, but did the other plans we had in mind (move to modules, hot runtime/rewrite to language worker, and improved module management), would this be fine to GA? |
|
+1 |
|
+1 because I am already using the PowerShell functions. |
|
+1 |
|
Yes just to echo @christopheranderson I imagine part of the concern is the note that says we don’t have plans to bring to v2 - that’s likely too strong of a statement. This week I’ve started working with Chris an others on how we can bring it to v2 the right way. What we don’t have now is an ETA as we do want to partner with PowerShell team in Microsoft to help us build it and we have a few pre reqs on our side to build right tools into platform. But in terms of getting us to prioritize PowerShell we do hear the demand for it and it’s definitely very high on our list (second only to Python in my opinion) and hoping to get work started on this very soon. We can continue to update as we learn more and progress. |
|
+1 |
|
@christopheranderson and @jeffhollan Thank you for those additional details. That confirms what I originally suspected. I had been chatting with some peers about what was on the wiki vs what seemed to be happening, but the recent updates to the wiki made me less confident. Based on your comments though, you are on the right path, and that is very promising. It would be better for the community if the wiki was reworded with a much more positive spin on it so that people don't get the wrong idea. Regarding working with SMEs as you add more languages, I have a high level of interest in seeing much better PowerShell support in Azure Functions, and would be happy to provide guidance and assist in this effort when you are ready to move forward with it. @christopheranderson, to answer your specific question, if you stayed on PowerShell 4 but pushed forward on the other plans you mentioned, I think that would be fine for me for GA, but I would like to look more closely at what exactly those other plans include and which of the issues identified in this issue would be resolved with the changes you have in mind before completely agreeing. I personally haven't had a need for PowerShell 5 in the Azure Functions runtime yet, and while I'll always advocate for the latest, a fixed/improved version 4 would be my priority. |
|
++ Microsoft, please support Piwershell as a first-tier language. |
|
@alexkarcher-msft adding PowerShell to the list of supported languages would allow a whole bunch of skilled Windows admins to move workloads to the cloud using the serverless paradigma. |
|
@jeffhollan: It's been a while since 11 nov 2017. Do you have an update on this? And maybe even an ETA? Would be really helpful! Thanks in advance! |
|
The PowerShell team started doing some investigation into the work required to make this happen. Last I heard they are still planning to help support us in building it but is a bit more work than they initially hoped to subscribe to our gRPC protocol. Targeting having this out in the coming months but can't commit to a more concrete ETA. Definitely a work item we are actively tracking - @asavaritayal specifically from our side |
|
We use small PowerShell functions which work with Office 365 and Teams, and use those functions in Logic Apps, Microsoft Flow and PowerApps. Very handy to write small posh functions compared to writing C# for many scenarios - and easier for clients to maintain afterwards, as most people in IT can comprehend the functions and make changes when needed. I'd be happy with Posh 4 in v1, but would rather see Posh Core support in v2. |
|
@wobba FYI that it is now 5.1 in the current runtime since they switched to 2016 on the backend. I agree that Posh Core support, especially if it can run on a slim Nano or Linux backend for functions, would be the "smart" way forward. |
|
Having worked with PowerShell in Azure Functions for a while now, the biggest problem I have is the Azure Function architecture, with multiple instances of functions run in a single process. It makes the whole notion of serverless go out the window when it comes to PowerShell, because there is no isolation from one Azure Function endpoint running PowerShell to the next if they are in the same Azure Function App. You have to think about whether or not different function instances use different versions of modules, or whether or not those modules do any caching, and if so, make sure they are in completely different function apps so that they are not run in the same worker processes, all of which is contrary to the notion of serverless where you shouldn't need to think about such details. I'm hoping that the Azure Function v2 runtime with container support and .NET core resolves this for me, such that individual invocations of Azure Functions are run isolated from one another in containers so that I don't need to think about any conflicts with modules or issues with caching performed by modules. |
|
@KirkMunro what you are describing today are limitations in the implementation of v1 experimental languages like PowerShell. This is one of the main reasons it is still experimental as we know in order to get it GA it needs to have execution isolation similar to what is provided with other languages. That said discussions for this are progressing. This is very high on our backlog right now and hope to have some deliverable in the coming months. It's too early to commit to anything but engineers are actively engaged on design and discussion of what it would take to bring PowerShell as a "GA-able" implementation for the v2 runtime |
|
@jeffhollan Thanks Jeff, that's what I was hoping. For the v2 runtime, with supported languages like C# today, can it be configured to run Azure Function workloads in container instances without reuse (i.e. where each invocation of a HTTP endpoint would result in the worker running inside of a container that is torn down upon completion, giving true isolation between function invocations)? |
|
@KirkMunro likely a separate thread / issue than this one but not really sure I understand the need here for tearing down between executions. This isn't a pattern unique to Azure that we keep an instance around between executions. You aren't required to share any state between executions, but you can (and often is hugely useful like being able to leverage an HttpClient or Sql Connection across multiple executions without having to instantiate from scratch every time). If using Kubernetes you wouldn't deploy and destroy a pod for every request, I don't know why you'd want that with functions either (but again this isn't the right issue for this conversation - you'd likely need to find/open another one) |
|
I agree this should be a separate issue tracking but it is a good
conversation to see happening and I for one look forward to the further
progress Jeff, we appreciate that this is prioritized.
…On Thu, Jun 21, 2018, 10:15 AM Jeff Hollan ***@***.***> wrote:
@KirkMunro <https://github.com/KirkMunro> likely a separate thread /
issue than this one but not really sure I understand the need here for
tearing down between executions. This isn't a pattern unique to Azure
<https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html> that
we keep an instance around between executions. You aren't required to share
any state between executions, but you can (and often is hugely useful like
being able to leverage an HttpClient or Sql Connection across multiple
executions without having to instantiate from scratch every time). If using
Kubernetes you wouldn't deploy and destroy a pod for every request, I don't
know why you'd want that with functions either (but again this isn't the
right issue for this conversation - you'd likely need to find/open another
one)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#585 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AOjVUgt4lWYqsrE_EForv04PPrp9UTk3ks5t-9ScgaJpZM4QZ1Hh>
.
|
|
+1 yeah this is definitely something me and my team would greatly appreciate being carried forward and enhanced for the v2 runtime! |
|
+1 posh core |
|
+1. |
|
@jeffhollan Hey Jeff been a couple months, any progress? Is the activity being tracked anywhere? Thanks for all your teams' hard work. |
|
@jeffhollan FYI AWS Lambda now supports Powershell Core, so you guys are in catch-up mode now... |
|
Hi everyone! Quick update on this - the Functions v2 runtime is now GA and we'll be using the new language extensibility model of v2 to build support for PowerShell. Please tune into the repo here - https://github.com/Azure/azure-functions-powershell-worker for feature/design discussion and updates. |
|
@asavaritayal PS Core 6 is still not supported or option is not available for creation in portal. Also the documentation says it is still experimental. see link below |
|
@vairamsvsjdo as he said it's coming, it's not available yet. It's in active development and you can follow the powershell worker repository for updates. I see daily updates but it still hasn't reached the preview state yet. |
|
+1. We already have PowerShell guys writing Azure Functions for monitoring so it would be good to have this fully supported in V2 at some point. |
|
Hi @asavaritayal , do you have any ETA for preview in Azure? |
|
@schwaizi In one of the last community calls, @joeyaiello mentioned that he can be contacted for private previews of it. |
|
We are actively working on supporting PowerShell in the v2 functions environment. We don't have a date for a public announcement yet, but will update this thread once available. The specific language worker effort can be tracked on https://github.com/Azure/azure-functions-powershell-worker |
|
I think this can be closed now that the azure functions powershell worker is in public preview, hopefully soon to be GA |
|
Closing. Thanks everyone for the help in getting PowerShell into Azure Functions. |
The Azure Functions Team is going the wrong way when it comes to PowerShell support. Your wiki docs currently state the following:
For v1 of the AzFx Runtime
For v2 of the AzFx Runtime (cross-platform support, currently in preview)
This paints a pretty poor picture for PowerShell use with Azure Functions, which is really a shame given how useful Azure Functions are and how powerful they can be with PowerShell support in them (although the "support" part can be worked around -- just write C# functions that invoke PowerShell cmdlets).
What will it take to get you to reprioritize this, such that you work with the PowerShell Team to get PowerShell Core support in v2 of the AzFx runtime, hopefully designed and implemented in a much better way than how you implemented PowerShell experimental support in the v1 runtime?
The text was updated successfully, but these errors were encountered: