Radius endeavors to provide rich resource audit and lifecycle management features for all kinds of resources. Radius can help the whole organization reason about their applications, the architectures and dependencies of those applications, and the cloud infrastructure that runs those applications.
In particular we're inspired by the capabilities of ARM (Azure Resource Manager) and we're generalizing those features to apply to all clouds. The ARM feature that users consistently rate as valuable is resource groups. Resource groups provide a way to list related resources, and to perform operations like RBAC assignment on the list rather than individual resources. Users can use resource groups to organize, audit and bulk-delete resources with a related lifecycle. While we often market Radius with statements like "graphs are better than list", it doesn't mean that the list is obsolete - they serve an important mechanical purpose.
Our vision for resource groups in Radius/UCP is that they provide the same capabilities as Azure resource groups, but that they can "contain" both Radius resources (like Applications.Core/containers) and cloud infrastructure resources (like an S3 bucket).
Every additional concept in Radius needs to fight for its life...
Due to the ARM lineage of Radius we're deeply entangled with the existance of resource groups. The design of Radius requires a user-defined scoping-construct for namespacing.
Resource groups in Radius exist today and they mostly operate in the background. Our tutorial content does not introduce Resource Groups as a concept, nor does it extoll their virtues.
To a new user, understanding and begeting resource groups is one more decision they will feel unprepared to make.
However resource groups are necessary for users once they need to:
-
- Explicitly manage RBAC assignments.
-
- "Bulk delete" of resources created by Bicep.
-
- Deploy more than one application to an environment.
-
- Deploy the same application to multiple environments.
The gap is that we don't prepare users for the jump in concept count they will experience when they need to do one of these actions. In the worst case our defaults will surprise them and put users on the back foot when their scenario becomes more complex.
We could solve all of these challenges with better defaults....
We need to create a resource group per-application per-environment:
-
Assumption: Each deployment needs to be isolated.
-
Assumption: Users will need to do more complex things and they should be able to override our defaults.
-
Each Radius tenant should support multiple environments.
-
Each Radius tenant should support deploying the same application to multiple environments.
-
Therefore we need to isolate each deployment per-application and per-environment.
What if Radius chose the resource group for you when you deploy?
- If we know the environment name and application name before deployment, we can generate the resouce group name.
rad deploy -e contoso-prod-east-us-2 -a icecreamstore->contoso-prod-east-us-2-icecreamstore- The environment and application name are usually required to deploy when an app is being deployed.
- Headache: we don't know whether a bicep file contains an app or not.
What if all of our list commands listed resources across all groups?
rad resource listwould be agnostic of resource groups
What about singular commands?
Some thoughts: