WebSockets on Azure Functions
We've received feedback from customers that Azure Functions should support WebSockets to enable realtime scenarios. See here for some discussion: https://github.com/Azure/azure-functions-host/issues/1139 There are some challenges here because WebSocket is really a stateful protocol (you have a long lived connection between a given client and a given server) while Azure Functions is designed to be stateless. For example, we will often deprovision a Function App from one VM and start it on a different VM (perhaps in a different scale unit) based on capacity constraints. This is safe to do for us today because of our stateless design - but if we did it when there were WebSockets connections to that VM, we'd be terminating those connections. There are also open questions from a billing perspective. Today the consumption plan for Azure Functions bills per execution, but if a WebSocket server is listening on an idle connection, this consumes resources but where are the "executions"? In summary, there are open issues around design, billing, and technical implementation. I think there are reasonable solutions to these issues and we just need to start working on them once this feature is high enough on our list of priorities.
Posted by paulbatum on Mar 27, 2018, 9:27 PM
Tags
Related issues
- I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
- As I replied in another comment[1], it's their software, their choice.
- [Feature] Support external model integration via personal API keys and local LLMs (BYOK)
- > So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
- Feature request: support multiple named accounts per app/connector
- Support standalone Windows installer (`codex-setup.exe`)
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
support (SaaS)
I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
NewAs I replied in another comment[1], it's their software, their choice.
[Feature] Support external model integration via personal API keys and local LLMs (BYOK)
> So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
Feature request: support multiple named accounts per app/connector
Support standalone Windows installer (`codex-setup.exe`)
[feature]: Move OIDC back to self-hosted OSS(Plane Free)
I was running about 1000 machines on VMware in my previous career.
WebSockets on Azure Functions
We've received feedback from customers that Azure Functions should support WebSockets to enable realtime scenarios. See here for some discussion: https://github.com/Azure/azure-functions-host/issues/1139 There are some challenges here because WebSocket is really a stateful protocol (you have a long lived connection between a given client and a given server) while Azure Functions is designed to be stateless. For example, we will often deprovision a Function App from one VM and start it on a different VM (perhaps in a different scale unit) based on capacity constraints. This is safe to do for us today because of our stateless design - but if we did it when there were WebSockets connections to that VM, we'd be terminating those connections. There are also open questions from a billing perspective. Today the consumption plan for Azure Functions bills per execution, but if a WebSocket server is listening on an idle connection, this consumes resources but where are the "executions"? In summary, there are open issues around design, billing, and technical implementation. I think there are reasonable solutions to these issues and we just need to start working on them once this feature is high enough on our list of priorities.
Comments (0)
No comments yet. Start the discussion.