10:00: welcome and coffee
10:15->11:00: First session: Governance and CNCF process
11:00->11: 45: Second session: Radius OSS project retro + direction setting
11:45->12:00: Break
12:00->12:30: Third session: Technical Strategy and Roadmap + Dapr
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 pr
- Status: SUPER pending
- Author: Ryan Nowak (
@rynowak)
To adopt Radius, we ask users to describe their application using Bicep and Radius' application model. Moving customer workloads to Radius' application model supports our strategy for the project, we're trying to evangelize a broadly-applicable cloud-native abstraction and then build multiple implementations of that abstraction. As the end goal: users that adopt Radius can seamlessly move between Kubernetes, on-premises platforms, and serverless hosting platforms provided by various clouds. Unfortunately migrating existing applications complicated and dangerous work. To make that worse, few customers actually need the kind of hosting platform portability we're planning, and we're a long ways off from building it. We believe that these factors explain much of the hesitation we're seeing from customers when they have experienced the problems that Radius is solving, but don't become enthusiastic a
Visual aids:
- API documentation
- Example API calls
- Component Diagram: https://excalidraw.com/#json=ZJfVrRxsbu8JKwKlcoCdN,yHZc3JnQAqe6YCBSm6DTrg
- API sequence Diagram: https://excalidraw.com/#json=MR2eRoGYwnysDEiqVGGjY,1DQ3eqw1A_DR5M-z0waWrA
Application Model: A document or API that describes a cloud application's configuration and requirements in a way that can be deployed and run.
Application models, delivery, and deployment tooling is a target-rich environment with many projects. Developers don't like application deployment and aren't good at it, but making developers more productive is always an important problem to solve. Complexifying this, there are many different models of how organizations work, whether they have separate disciplines, and which people have different responsibilities.
The result is that there's a huge diversity of a projects, no standard terminology, and no one project gets critical mass.
This document is the starting point for a Recipes test plan. The goal of this document is that we can have a brainstorm together and fill in the plan with input from the whole team. @rynowak will hold the pen for writing the final document, and @kachalwa is the approver. The work that's detailed here will feed into the individual items being driven by feature owners (functional tests are part of the definition of done).
Our goal for this discussion is to introduce the idea of a test plan, collect, and refine input.
We're doing this now because we're executing on Terraform recipes in a highly parallel well. Getting a shared understanding of the test strategy will help individuals build the right tests by doing some big-picture-thinking upfront.
We've also had a lot of churn in our design practices for tests and recently done some thinking about concepts like:
rynowak
/ tracked_resources_notes.md
Last active
September 6, 2023 19:00
Notes on the implementation of tracked resources
rynowak
/ public_release_plus_one_planning.md
Last active
July 12, 2023 19:18
This document provides framing for public release +1 - meaning: what are the next set of goals and investments for Radius post-public-release.
Since we moved our announce date back we'll have time to do more before the actual initial release. Additionally we need to build a public roadmap and publish it as part of the project. This document acts as an input to support both those goals.
Our goals for public release as started original were:
Written by the shores of Lake Tahoe.....
This document is the overall framing of a Radius workshop that we would produce. The goals of this document are to:
- Align the team on the purpose of the workshop and format.
- Align the team on an overall outline so we can assign owners and start work.
NewerOlder