🎓 Practical Workshop: Deploy Different API Strategies with Minimal Code Changes

[macalbert]

🎯 Workshop Objective

This PR demonstrates how to deploy three different API strategies using the same CDK infrastructure with minimal configuration changes. Perfect for hands-on learning and comparing deployment approaches!

🔧 Three Deployment Strategies - One Simple Switch

Strategy Selection in workshop/src/iac/bin/iac.ts

const dockerfileApi = path.join(
    rootPath,
    // Strategy 1: Custom .NET with package RIC
    // "workshop/src/apps/Minimal.Api/Dockerfile"

    // Strategy 2: Python with AWS Lambda public ECR image  
    // "workshop/src/apps/FastApiApp/Dockerfile"

    // Strategy 3: Python with custom slim image + RIC (ACTIVE)
    "workshop/src/apps/FastApiApp/Dockerfile.ric"
);

📝 Workshop Exercise: Simply uncomment the desired strategy and deploy!

---

📊 Deployment Strategies Comparison

Strategy	Base Image	Runtime	Cold Start	Best For	One-Line Change
🔵 .NET Minimal API	mcr.microsoft.com/dotnet/aspnet:9.0-alpine	.NET 9.0	~10-30s	Enterprise APIs	✅ Comment change
🟢 FastAPI (AWS Lambda)	public.ecr.aws/lambda/python:3.9	Python 3.9	~2-5s	Serverless-first	✅ Comment change
🟡 FastAPI (Custom RIC)	python:3.9-slim + RIC	Python 3.9	~3-7s	Custom requirements	✅ Comment change

---

🎯 Strategy Deep Dive

Strategy 1: .NET Minimal API

# Multi-stage .NET build with Alpine runtime
FROM mcr.microsoft.com/dotnet/aspnet:9.0-alpine AS base
# Full enterprise-grade API with Swagger, versioning, auth

• Use Case: Enterprise applications, existing .NET teams
• Features: Built-in authentication, API versioning, comprehensive logging
• Endpoints: /health, /greetings, Swagger docs

Strategy 2: FastAPI with AWS Lambda Base Image

# AWS-optimized Lambda runtime
FROM public.ecr.aws/lambda/python:3.9
# Direct Lambda integration, no custom RIC needed

• Use Case: Pure serverless, AWS-native deployments
• Features: Optimal cold start, built-in Lambda integration
• Endpoints: /, /health, /info, /echo

Strategy 3: FastAPI with Custom RIC ⭐ Currently Active

# Custom Python runtime with RIC package
FROM python:3.9-slim
RUN pip install awslambdaric
ENTRYPOINT [ "/usr/local/bin/python", "-m", "awslambdaric" ]

• Use Case: Custom requirements, hybrid deployments
• Features: Full control over base image, custom dependencies
• Endpoints: /, /health, /info, /echo

---

🚀 Workshop Instructions

Quick Strategy Switch & Deploy

1. Choose Your Strategy (edit workshop/src/iac/bin/iac.ts):

   # Open the file and uncomment your preferred strategy
   code workshop/src/iac/bin/iac.ts

2. Deploy in One Command:

   cd workshop/src/iac
   cdk deploy --all

3. Test Your Deployment:

   # Get API Gateway URL from CDK output
   curl https://your-api-gateway-url/health
   curl https://your-api-gateway-url/info  # Shows deployment strategy!

📱 Compare Deployment Info

Each strategy exposes its configuration via the /info endpoint:

{
  "runtime": "FastAPI",
  "deployment_type": "lambda",
  "container_info": {
    "image_type": "python:3.9-slim",     // Shows current strategy
    "runtime_interface": "ric"           // Shows integration method
  }
}

---

🎯 Workshop Learning Outcomes

💡 Key Lessons

• Infrastructure Flexibility: Same CDK code, different runtimes
• Strategy Trade-offs: Cold start vs. control vs. optimization
• Container Strategies: Base image selection impact
• Serverless Patterns: Lambda integration approaches

🔄 Easy Experimentation

• Switch between strategies with one line change
• Compare performance and behavior side-by-side
• Understand when to choose each approach
• Learn container optimization techniques

📈 Real-World Applications

• Migration Planning: Evaluate options before committing
• Multi-Runtime Support: Support different team preferences
• Cost Optimization: Compare pricing models
• Performance Tuning: Test different runtime optimizations

---

🔍 Current Configuration

Active Strategy: Python with Custom Slim Image + RIC

• File: workshop/src/apps/FastApiApp/Dockerfile.ric
• Advantages: Smaller base image, full control, custom dependencies
• Trade-offs: Slightly longer cold start vs. AWS Lambda base image

---

🛠️ Technical Implementation

Dockerfile Comparison

AWS Lambda Base (Dockerfile):

FROM public.ecr.aws/lambda/python:3.9  # AWS-optimized
CMD ["lambda_handler.lambda_handler"]   # Direct integration

Custom RIC (Dockerfile.ric):

FROM python:3.9-slim                              # Smaller base
RUN pip install awslambdaric                      # Add RIC manually
ENTRYPOINT ["/usr/local/bin/python", "-m", "awslambdaric"]  # Custom entry

Environment Variable Tracking

Each strategy sets identifying environment variables:

• DEPLOYMENT_TYPE: lambda | fargate
• IMAGE_TYPE: Base image identifier
• RUNTIME_INTERFACE: direct | ric

[gemini-code-assist]

Summary of Changes

Hello @macalbert, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the project's workshop capabilities by introducing and configuring multiple Docker-based API deployment strategies within a unified CDK infrastructure. It aims to provide a clear, hands-on comparison of different containerization approaches for serverless applications, making it easy for users to experiment with and understand the trade-offs of each strategy.

Highlights

• Workshop Structure & Strategy Comparison: This PR introduces a practical workshop setup to demonstrate and compare three distinct API deployment strategies (.NET Minimal API, FastAPI with AWS Lambda base, and FastAPI with custom RIC) using a single CDK infrastructure, allowing easy switching between them for hands-on learning.
• FastAPI Dockerfile Updates: The FastAPI application now includes a new Dockerfile.ric for a custom slim image with AWS Lambda Runtime Interface Client (RIC), and the existing Dockerfile.lambda has been renamed to Dockerfile and updated for the AWS Lambda public ECR image strategy. The old Dockerfile.public has been removed.
• Infrastructure Configuration: The CDK infrastructure code (iac.ts) has been updated to default to the FastAPI custom RIC strategy, with clear comments enabling quick switching to other deployment options for the workshop participants.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request sets up an excellent workshop for comparing different API deployment strategies. The changes are well-structured and easy to follow. My feedback primarily focuses on optimizing the Dockerfiles to follow best practices for layer caching and minimizing image size, which are important concepts for the workshop. I've also suggested a change to the local development server port to avoid potential permissions issues.