Serverless container runtime

[willtsai]

Overview of roadmap item

Given the importance of serverless infrastructure in the modern application landscape, it is a priority for Radius to support serverless resources. The initial expansion will focus on support for an unopinionated serverless container runtime before exploring integrations with other serverless platforms.

Related issues

Related issues

Beta Give feedback

1. Serverless container runtimes radius#7648
   feature triaged +2

Additional context

[willtsai]

Note, here is a comment from the community with feedback: radius-project/radius#6964 (comment)

[itpropro]

Really looking forward to using Radius with Container Apps!

[itpropro]

I would like to reiterate here, as the lack of support for serverless runtimes has become the main blocker for adopting radius at most companies I talked to.
It is currently not possible to create and deploy a fully cloud native application with radius that can seamlessly scale (to zero), uses purely serverless/platform services and has an event driven architecture. This is mainly due to the lack of serverless runtime support, but also caused by the dependency to run radius itself in a Kubernetes cluster (which is a different issue).

Since serverless has settled as a standard for many scenarios and edge computing, especially with technologies like workers supported by things like WASM, is more and more becoming an essential part of modern application architectures, Radius should support these patterns as a first party feature.
This includes support for Container Apps and Container Instances on Azure, Fargate on AWS, but also modern serverless databases like Turso or Neon as well as support for native serverless runtimes like Cloudflare Workers or Wasm focused services like Wasmer that go beyond containers.

I know that many of this is probably far in the future for radius, but what I would encourage for the short term is to have a runtime model that is easily extendable with new runtimes and which supports custom runtime bindings that don’t need to be part of the core of radius.
This way it’s much easier to respond to development trends and to give projects the possibility to manage their complete application architecture with radius, independent of runtime choice, where they are currently forced into Kubernetes.

[itpropro]

Hey @willtsai ,
great to see that this is taken over by you! Is there anything I can do to support here or any additional feedback that would help you?

[itpropro]

Any updates @willtsai ?

[willtsai]

@itpropro - hello, apologies for missing your comments before! This remains as one of the top items in our roadmap and backlog. I'll be working on the feature spec soon and will definitely reach back out with questions on user scenarios, etc. thanks!