search

radius-project / roadmap

https://radapp.io
Apache License 2.0
0 stars 0 forks source link

Serverless container runtime #23

Open willtsai opened 6 months ago

willtsai commented 6 months ago

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
- [ ] https://github.com/radius-project/radius/issues/7648

Additional context

willtsai commented 5 months ago

Note, here is a comment from the community with feedback: https://github.com/radius-project/radius/issues/6964#issuecomment-1868268817

itpropro commented 5 months ago

Really looking forward to using Radius with Container Apps!

itpropro commented 2 months ago

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.