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:
- Build a cloud-native application management solution that customers love. Radius feels like a natural way for IT Pro and Developers to work together on defining, deploying, and managing their applications.
- Drive industry adoption of Radius. To do this, we’ll make Radius open-source and multi-cloud. Then we’ll make sure partners and customers understand how to use Radius, how to extend Radius, and how to change Radius.
- Foster a vibrant open source community around Project Radius
- Platform engineering is the philosophy of must customers we have dialogue with: how can the platform team set up developers for success?
- We should talk more to customers about workflows then can enable, including the touch points outside of Radius (Day 2).
- Every customer we talk to has in-house resource types and APIs. They are extending Kubernetes by default because we haven't given them another way.
- App-iness is sticky with customers but the story is incomplete without ways to demonstrate it.
This area includes a basket of changes to deliver a complete e2e for resource management that works the same across Radius, AWS, and Azure.
Summary: Users can use Bicep to deploy resources across Radius, AWS, and Azure.
Size: L
Why: Supports goals 1) and 2) by demonstrating our vision for multi-cloud resource management tools and workflows across the whole application lifecycle.
Why Not? Many technical pre
Summary: Create a Radius workshop that teaches Radius from both the developer and platform engineer perspective.
Size: XL
Why: Supports goals 2) and 3) by providing a scalable onramp for users to learn Radius and its concepts.
- We can use the workshop to promote Radius at conferences and meetups.
- Users can complete the workshop self-guided.
Summary: Build a minimal dashboard website and integration with Backstage. This would include basic visibility (read only) into API objects like Applications, Environments, and Containers, as well as visualization of the application graph.
Size: XL
Why: Supports App-iness via visualization. Helps a cohort of non-CLI-native users understand Radius.
Why not? Not strongly aligned with any of our defined PR goals.
Summary: Support arbitrary customization of Radius' generated outputs like Kubernetes services. Allows operators and extenders to build their own mixins for Radius that extend the vocabulary. Refactor Dapr support to use extensions.
Size: M
Why: Empowers platform engineers and enables many production scenarios.
Why not? Focused on production use-cases. Not clear that it's an adoption blocker.
Summary: Users can write their own resource providers to extend Radius. This can be data-driven (like a CRD) and backed by Recipes, or can be implemented in code in an arbitrary language.
Size: L (XL with user-defined-types)
Why: Supports goal 2) by making Radius easily extensible. Enables enterprise use of Radius for in-house services and APIs. Enables 3rd party extensibility from other OSS projects.
Why not? Timing may not be right. Do we have customers or partners that are ready to extend Radius?
Summary: Provide examples, guidance, and feature support for Day 2 workflows where teams start to adopt Radius in earnest. Initial focus is on platform engineering team templating repositories that are shovel-ready for developers to build and iterate on an application.
Size: M (some ambiguity)
Why: This is squarely aligned with goals 1) and 2) as this would level up the messaging around Radius and speak to both developers and platform engineers. Provides guidance and support needed by customers who are not on the cutting edge.
Why not? Still highly ambiguous.
Summary: Implement previously designed features for incremental adoption of Radius as a Kubernetes user. Write documentation and migration guidance.
Size: M
Why: This is aligned with goal 2) as a strong adoption blocker, and is based on our hands-on learnings from Radius hackathons. This allows arbitrary customization of Radius' Kubernetes outputs and so enables a variety of features without much work.
Why not? (none - this was a hard cut from before)
Summary:
Size:
Why:
Why not?
Summary:
Size:
Why:
Why not?