Model and deploy 10 most commonly used AWS services via Radius

[Reshrahim]

Overview of the feature request

This feature is to validate the modeling and deployment of the most commonly used AWS services via Radius. This is an exercise to learn the unknowns in the AWS space and figure out the plan for Radius to fill in gaps via features and documentation

Features

Phase 1

• Create a reference app guide to model and deploy a Amazon Relational Database Service (Amazon RDS) instance based on AWS tutorial references #4106
• Create a reference app guide to model and deploy a Amazon Simple Storage Service (Amazon S3) instance based on AWS tutorial references #4107
• Create a reference app to model and deploy a Amazon SQS instance based on AWS tutorial references #4108

[asilverman]

Here is a list of AWS services that are commonly used as part of a con

Storage/Caches

• Amazon Relational Database Service (Amazon RDS). - Covered by Create a reference app guide to model and deploy a Amazon Relational Database Service (Amazon RDS) instance based on AWS tutorial references #4106
• Amazon DynamoDB
• Amazon ElastiCache
• Amazon Elastic Container Registry (ECR)
• Amazon DocumentDB - Not supported in CloudControl API

Connectivity, Queues, PubSub

• Amazon SNS - Not supported in CloudControl API
• Amazon SQS Covered by Create a reference app guide to model and deploy a Amazon Simple Storage Service (Amazon S3) instance based on AWS tutorial references #4107
• Amazon API Gateway
• AmazonMQ - Not supported in CloudControl API

Content Delivery

• Amazon CloudFront
• Amazon Simple Storage Service (Amazon S3) Covered by Create a reference app to model and deploy a Amazon SQS instance based on AWS tutorial references #4108
• Amazon Kinesis

Compute

• Amazon Elastic Kubernetes Service (Amazon EKS)
• Amazon Step Functions
• Amazon Lambda

Identity, Security, Networking

• Amazon VPC
• Amazon Route 53
• AWS Identity and Access Management (IAM) roles.
• AWS Key Management Service (KMS)
• Amazon Cognito - Not supported in CloudControl API
• Amazon Certificate manager

[AaronCrawfis]

One thing I want to make sure we think through is what Radius lesson/skill are we teaching in each quickstart? If all of the above quickstarts are identical except for the AWS resource being modeled, then I would argue we only need one of them: a quickstart on modeling and deploying AWS resources. Having more than one makes all of them redundant.

Radius quickstarts shouldn't have the main focus be on an external service/concept. You shouldn't learn how to use an S3 blob container in a Radius quickstart, that's what the AWS docs are for. Instead, you can refer to the single "AWS quickstart" to learn how to do AWS, and then swap the resource out for S3.

If there are AWS tutorials or examples you want to highlight and "rad-ify", then I would recommend doing a Radius "reference application". We can have an open set of those, focused on rad-ifying other tutorials.

I see these fitting much better as a reference app instead of a quickstart.

[asilverman]

I think that there are multiple value propositions to this exercise:

1. We want to identify gaps and common questions that will arise as people begin modeling AWS services in Radius
2. We want to reduce the barrier for adoption for people transitioning their application models from where they are and to Radius. By offering these samples the customers can use them as a starting point for their own modeling.
3. We believe that these can in the future be published and exposed as recipes of sorts
4. We are looking to learn about common AWS Services and their applications in the product domain of Radius
5. We want to use the building blocks resulting from this exercise to compose a full reference application from AWS Architecture Blog to prove the value proposition of Radius

[Reshrahim]

Since bicep extensibility provider is built by us for AWS resource types, I think we'll have to provide enough to the AWS users trying to model and deploy different AWS resources in Bicep.

I agree quickstarts may not be the ideal place to put this content as Quickstarts are dedicated towards teaching a concept.

Long back when we did the competitive analysis on AWS Proton Template , one of the things that we wanted to do differently was to expand our reference apps samples like the extensive template library AWS proton has. This feature will help us move a step toward that.

Maybe we can rename the Reference apps page to Sample templates or Reference templates and have all the below content grouped underneath it.

AWS

• Environment templates
  • Sample env template with VPC, IAM role, and EKS cluster all modeled in Bicep
  • Recipes
• Resource templates
  • Templates to model S3/ RDS/Memory db
• App templates (Reference apps)
  • AWS vetted reference architectures radified

This will help

1. Ops and developers to discover sample content at various levels within Radius.
2. We can promote best practices via these templates
3. Ops and developers do not have to do back and forth between AWS docs and Radius (This will not go away completely, at least one step towards making it easier for them )

Similarly, we can have the content grouped for Azure and Kubernetes as well

Kubernetes

• Environment templates
• App templates (Reference apps)
• Service templates

Azure

• Environment templates
• App templates (Reference apps)
• Service templates