Feature Spec: Serverless Container Runtimes #77
Conversation
Signed-off-by: Will Tsai <[email protected]>
willtsai
changed the title
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Co-authored-by: Zach Casper <[email protected]> Signed-off-by: Will <[email protected]>
Co-authored-by: Zach Casper <[email protected]> Signed-off-by: Will <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Co-authored-by: Zach Casper <[email protected]> Signed-off-by: Will <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
|
|
||
| > Note: We assume that the `sku: 'Confidential'` property for ACI (and other comparable properties across platforms like ECS) is scoped to the individual container and not the entire application or environment. We will need to validate this assumption as a part of the implementation. | ||
|
|
||
| > Note: To make the app definition portable, we must allow several `runtimes` to be declared per container and these should all be optional for cases where the user wants to punch through the Radius abstraction. If they declare a `runtimes` property that doesn't match the targeted deployment environment's compute, we should simply ignore that property for that deployment. If they haven't declared any `runtimes` property that match the compute of the targeted deployment environment, then we should deploy their container assuming that no `runtimes` property was provided and thus no "punch-through" behavior will be applied. |
There was a problem hiding this comment.
Does this also mean that an application could specify a punch through that is not used when deployed to a different environment? For example, could a user specify a K8S punch through and still deploy the app to ACI, in which case the K8S punch through would be ignored? If yes, then I agree. 👍
There was a problem hiding this comment.
Maybe a good future feature would be the ability to add additional platform-specific properties in downstream environments, similar to what a GitOps workflow would allow. For example, the dev specifies a K8S property and the operations person overrides that in production with a different value.
There was a problem hiding this comment.
For example, could a user specify a K8S punch through and still deploy the app to ACI, in which case the K8S punch through would be ignored?
Yes, this is exactly what I'm proposing, glad you agree :)
For example, the dev specifies a K8S property and the operations person overrides that in production with a different value.
For this one, are you saying that we should add the ability to apply universal container configurations at the environment level that would override the container configurations defined within individual applications? If so, I can see a use case for this but I wonder if that's something RBAC (when that feature is available) can take care of? For example, the sku of the container compute is specifiable in the environment and then RBAC rules prevent developers from overriding sku configurations from within their application definitions.
|
|
||
| After successful deployment, the user can view the serverless containers in the CLI using the `rad app graph` command or via the Application Graph in the Radius Dashboard. | ||
|
|
||
| ## Key investments |
There was a problem hiding this comment.
Should we add a key investment for Radius managing external environments? This could be a separately deployable feature that has value on its own, but it is definitely required for ACI support.
There was a problem hiding this comment.
I added a note in the risks section (see Risk: Deploying to multiple clusters ) where I call out that we might have to partially implement (or at least take into consideration) the Inter-cluster app deployment and management feature. I hesitate to add this to the explicit set of features we plan to deliver as that itself is a separate (and possibly large) project that we probably don't want to fully implement as a subproject of serverless. In other words, we should only build enough functionality for Radius managing external environments that will satisfy our Serverless features. Let me know if you disagree and we can discuss further.
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
…into serverless-compute
| + // all the other container properties should also be implemented (e.g. `env`, `readinessProbe`, `livenessProbe`, etc.) | ||
| } | ||
| extensions: [ | ||
| + { |
There was a problem hiding this comment.
Would we need to specify a runtime under extensions, or are we planning to match element names? If we are matching element names, we could run into naming conflicts where the same name means different things on different platforms.
There was a problem hiding this comment.
I think as a part of the tech design we should address this and change the schema if it makes more sense because I agree with your point.
| > Must be sure to include serverless platform specific customizations via a `runtimes` property, similar to how Kubernetes patching was implemented for [containers](https://docs.radapp.io/reference/resource-schema/core-schema/container-schema/#runtimes). | ||
|
|
||
| Allow for Radius abstraction of a [container](https://docs.radapp.io/reference/resource-schema/core-schema/container-schema/) resource that can be deployed to serverless compute platforms. Must be sure to include serverless platform specific configurations via [connections](https://docs.radapp.io/reference/resource-schema/core-schema/container-schema/#connections), [extensions](https://docs.radapp.io/reference/resource-schema/core-schema/container-schema/#extensions), and routing to other resources via [gateways](https://docs.radapp.io/reference/resource-schema/core-schema/gateway/). | ||
| > One future idea to explore is whether we can we build extensibility via UDT and Recipes - i.e. allow Recipes to deploy predefined Container types, which themselves can be serverless containers. In other words, developers can deploy a UDT container resource using a Recipe such that all the user has to do when declaring a container is specifying the bare minimum (e.g. name, application) and let the predefined Recipe handle the rest. This will require the implementation of UDTs (e.g. defining specific types of containers as individual resource types). |
There was a problem hiding this comment.
This would require us to add something like UDE (User-Defined Engine) since we will need the necessary engine (or driver) for that runtime.
There was a problem hiding this comment.
And then the UDT can choose the driver that it needs to use.
|
|
||
| ### Scenario 2: Define and create core resources (i.e. Gateway, Secret Store, Extender) for use in serverless containers | ||
| <!-- One or two sentence summary --> | ||
| Enable the ability to define and create core Radius resources (i.e. Gateway, Secret Store, Extender) for use in serverless containers. Radius would leverage the solution available on the hosting platform to create and manage these resources. For example, if the serverless compute platform has a built-in secret store, Radius would use that instead of creating its own. This would allow for a consistent experience across different serverless compute platforms while still leveraging the unique features of each platform. |
There was a problem hiding this comment.
Extender is a very open ended resource type, so I don't think it fits the category this scenario captures.
There was a problem hiding this comment.
Good point, moved it out to its own scenario
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
Signed-off-by: Will <[email protected]>
Signed-off-by: Will <[email protected]>
Signed-off-by: Will Tsai <[email protected]>
…gn-notes-radius into serverless-compute
add feature spec for Serverless Container Runtimes