Feature request: "on-demand" mode for Radius control plane

Overview of feature request

Today the Radius control plane stores the state of its applications in a datastore (etcd) on the cluster. There's an effort currently underway to enable the use of an external data store provided by the user, supporting PostgreSQL as a start (see roadmap item # 49).

This request is to take advantage of the external data store to enable an "on-demand" or "serverless" mode for Radius, where the control plane can be spun up and taken down on demand while the Radius state is maintained in the persistent database that is external to the Radius control plane.

With this in place, Radius will enable user scenarios such as:

• As a user, I can spin up a Radius control plane on a local cluster within my CI/CD pipeline (e.g. within GitHub Actions) where the workflow would initialize Radius using an existing state stored externally, perform app and resource deployments, store the new application states, and then spin down the control plane and cluster after successfully executing the CI/CD operations.
• As a user, I can host the Radius control plane on a serverless compute platform that I may spin up and down as needed based on demand.

Acceptance criteria

1. Radius is able to store its state into a database external to the cluster that hosts its control plane.
2. The Radius control plane can be initialized from scratch in a fresh cluster using the existing state stored in the external database.
3. The Radius control plane can store its state in the external database when it performs various operations like deployment, API calls, logging, etc.
4. The Radius control plane and its cluster can be spun down without impact to its externally stored state, which can subsquently be used to initialize a new instance of the control plane in a fresh cluster (i.e. Step 1 above)

Additional context

related and dependent on: https://github.com/radius-project/roadmap/issues/49

Would you like to support us?

• Yes, I would like to support you

Start by reading roadmap item #49 and the external datastore effort described in this issue to understand the existing PostgreSQL integration. Compare the implementation against the four acceptance criteria, including initialization from persisted state, state writes during operations, and safe control-plane shutdown and restart.