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.
Goals of the Radius team:
- Produce educational content we can use to evangelize Radius.
- Cover both developer and operator perspectives to include our whol audience.
- Collect feedback from presenting/teaching the workshop content.
- Workshop acts as a prioritization tool.
- Writing the workshop is a forcing function to cover complete end-to-ends with included troubleshooting.
- By definition the features in the workshop are priorities.
User experience goals:
- Users make a code change in every step, users feel like they are building something, not just copy-pasting.
- Users feel like the content is relevant to them (choose widely known languages and tools).
- Users can get up and running quickly without crazy amounts of toil for environment setup and access control.
I (@rynowak) have successfully built workshop content in the past. Here's an example. The Blazor workshop has a mature format that's been maintained over multiple major release of the underlying product.
The overall format of the workshop switches between instructor-led sessions and lab sessions. Each chapter contains one instructor-led session that introduces a concept with demos and a lab session that gives participants a chance to use the concepts.
You can find example speaker's notes here. You can find an example of a lab section here.
The instructor-led sessions necessarily duplicate some of the content from the lab instructions. This is because users can do the workshop self-guided and so the instructions need to stand on their own.
We'll go into detail when we get closer to execution.
The workshop should be centered around an end-to-end application that demonstrates Radius' features. Building an application that grows in complexity over the whole workshop helps users maintain context and gives an overall sense of accomplishment from completion.
The right application will:
- Include several microservices and multiple communication paradigms.
- Include a basket of operational features we want users to experience (diagnostics, CI/CD).
- Easily run on a developer workstation or in the cloud.
- Use a variety of dependency resources (eg: mongo, redis, SQL, etc)
- Have a fun theme.
- Have permissive rights (we need the right to make changes, claim that it's ours, etc.)
- Use programming languages that are easy to pick up and widely used (eg: Python, JS).
From a survey of existing example applications, several of these kinds of samples exist in the wild.
I think our best option is to start with the eShop sample and adapt it for our needs. We're in touch with the owners so we could easily get permission to "fork" and maintain our own branded sample.
The only criteria not met are having a fun theme (.NET merchandise) and not using a common programming language (.NET/C#). I propose that we keep the overall architecture and application structure the same and that we re-brand and port the application to another language.
The major benefit to choosing eShop is that we're already organizationally aligned with it, we use it as a sample already. The team knows it well, and it's a great sample for demonstrating Radius' capabilities. Aligning the workshop around a variant of eShop will answer (in advance) any doubts about whether the workshop has the right sample content.
Some partners are interested in developing a workshop or collaborating with us on the development. What's important here is that we first align on the outcomes we want and then have the partner discussion.
Ultimately may see have involvement from partners, or we may see a duplicated effort from partners. Either way helps us achieve our goals.
- Introduce Radius
- Introduce workshop format
- How to get help
- Overall agenda
- Check prerequisites
- Installation of tools
- Access to cloud accounts
- Connectivity to needed resources
- Install Radius on Kubernetes together (as a class)
Goal: users are ready to begin the lab!
- Introduce first concepts
- Containers
- Recipes
- Walkthrough first application (as a class)
rad initrad run
Goal: users have deployed their first application!
- Introduce the application
- Introduce developer loop
- Making code changes
- Publishing containers
- Doing deployment with Radius
- Describe more advanced compute features
- Troubleshooting and what can go wrong
Lab: users build and deploy the frontend application.
Goal: users can build and deploy the containers in the repo.
- Introduce service discovery and HTTP
Lab: users build and deploy a backend service, hook up communication from frontend.
Goal: users understand basic networking and service-to-service communication.
- Introduce Application and Environment concepts in Radius
- Understanding concepts via CLI, dashboard
- Setting up CI/CD pipelines with integration tests
- Multiple applications, multiple environments
Lab: users create CI/CD pipelines in GH actions.
Goal: users understand the application and environment concepts, how to use environments for CI/CD.
- Introduce "links" and talk about what Radius provides
- Example: using a dependency resource to model an external resource
- Example: using a dependency resource with a recipe
Lab: users add a dependency of the backend using a Recipe.
Goal: users understand the role of dependency resources in Radius, how to use them as a developer.
... More to come ...