Pass Equity: Azure Compute Skills Lifecycle Parity — 11 PRs open for SME review

[paulyuk]

Summary — Pass Equity Scorecard

"Pass equity" measures whether a developer gets an equally good AI-assisted experience regardless of which Azure compute service they choose. Today, the experience is uneven — Azure Functions gets deep investment across most lifecycle phases while Container Apps and App Service have significant gaps.

⚠️ Starting Assessment & Proposal — This is an initial assessment based on automated skill auditing and prior research (session 8fc96f69, March 25 2026). Each PR proposal below is a starting point. We will leverage collaboration from each service/domain expert to modify or contribute what they believe is essential. The grades and gap analysis reflect current skill file coverage, not platform capability.

Overall Grades (A–F scale)

Lifecycle Phase	App Service	Container Apps	Azure Functions	Equity Gap
Develop (scaffold, code gen)	C	C	A	🔴 High
Deploy (IaC, provisioning)	A	A	A	🟢 Equitable
Operate (config, scaling, day-2)	B+	C	B	🟡 Medium
Diagnose (troubleshoot, logs)	B	B+	B	🟡 Medium
Migrate (cross-cloud)	F	F	A	🔴 Critical
Observe (monitoring, APM)	A-	B	B	🟡 Medium
Secure (RBAC, compliance)	A	A	A	🟢 Equitable
Overall	B-	C+	A-

Pass Equity Score: 62% — 11 cells below A across 5 lifecycle phases

---

Gap Specifications — One Sub-Issue Per Equity Gap

Each gap below is tracked as a linked sub-issue with detailed specifications. Actual Pull Requests implementing the fix will reference the sub-issue they close.

Each sub-issue describes: the current gap, what "A grade" looks like (learned from the highest-scoring service), the specific deliverables, and key scenarios informed by Azure Learn docs and MCP tool capabilities.

---

Gap-1: App Service Develop (C → A)

Learning from: Functions (A) — 200+ template files, composition algorithm, 6 runtimes, 9 recipe integrations

Current state: 4 reference files (README, bicep, scaling, deployment-slots). No code generation, no app templates, no multi-language scaffolding.

What "A" looks like for App Service:
App Service's key scenarios differ from Functions — they're long-running web apps and APIs, not event-driven functions. Templates should reflect this.

Deliverables:

• services/app-service/templates/selection.md — Decision tree: Web API vs full-stack web app vs background worker (WebJobs)
• services/app-service/templates/composition.md — Composition algorithm (base + database + auth + caching recipes)
• Base templates: web-api.md (REST API), web-app.md (MVC/Razor/React SPA), worker.md (WebJobs/background)
• Recipe templates (per language: C#, Python, Node.js/TS, Java):
  • recipes/sql/ — SQL Database integration with EF Core / SQLAlchemy / Prisma / JPA
  • recipes/cosmos/ — Cosmos DB integration
  • recipes/redis/ — Azure Cache for Redis
  • recipes/auth/ — Entra ID / Easy Auth integration
  • recipes/storage/ — Blob Storage file handling
• Language-specific source templates: source/dotnet.md, source/python.md, source/javascript.md, source/java.md
• Eval templates: eval/summary.md per recipe
• Update azure-prepare routing to load App Service templates for web app requests

Key scenarios (from Azure Learn):

• RESTful Web APIs (ASP.NET Core, Flask/FastAPI, Express, Spring Boot)
• Full-stack web applications with server-side rendering
• Background processing with WebJobs (queue polling, scheduled tasks)
• Multi-slot deployment with staging/production swap

---

Gap-2: Container Apps Develop (C → A)

Learning from: Functions (A) — composition algorithm with base + recipes

Current state: 5 reference files (README, bicep, scaling, health-probes, environment). No code generation, no container templates.

What "A" looks like for Container Apps:
Container Apps is a general-purpose serverless container platform that hosts any app stack and SDK at high scale. Key scenarios include high-scale serverless web apps, microservices with Dapr, background workers, and jobs. Event-driven processing (triggers, bindings) is best handled by Functions on Container Apps — bringing the Functions programming model into the Container Apps environment.

Deliverables:

• services/container-apps/templates/selection.md — Decision tree: High-scale serverless web app vs microservices vs background worker vs job vs Functions-on-Container-Apps (event-driven)
• services/container-apps/templates/composition.md — Composition algorithm (base + sidecar + integration recipes)
• Base templates:
  • web-app.md — High-scale serverless web apps (any stack: Node.js, Python, .NET, Java, Go, Rust)
  • api.md — REST/gRPC API services with ingress, auth, and scaling
  • microservice.md — Multi-service architecture with service discovery
  • worker.md — Background processing / long-running tasks
  • job.md — Container Apps Jobs (scheduled, event-triggered, manual)
  • functions-on-aca.md — Functions hosted on Container Apps (event-driven processing with triggers/bindings in container environment)
• Recipe templates (per language: C#, Python, Node.js/TS, Go, Java):
  • recipes/dapr/ — Dapr service invocation, state management, pub/sub
  • recipes/cosmos/ — Cosmos DB integration
  • recipes/servicebus/ — Service Bus integration with KEDA scaling
  • recipes/eventhubs/ — Event Hub consumer with KEDA scaling
  • recipes/redis/ — Redis state store / cache
  • recipes/acr/ — ACR build + push + deploy workflow
  • recipes/postgres/ — PostgreSQL Flexible Server integration
• Dockerfile templates: Per language with multi-stage builds (Node, Python, .NET, Java, Go)
• Eval templates: eval/summary.md per recipe
• Update azure-prepare routing to load Container Apps templates for container/microservice/serverless web app requests

Key scenarios (from Azure Learn + domain input):

• High-scale serverless web apps — Any stack/SDK with auto-scaling (including scale to zero), custom domains, managed TLS
• Microservices with service discovery, traffic splitting, and Dapr integration
• Functions on Container Apps — Event-driven processing using Functions triggers/bindings running in the Container Apps environment
• Background workers — Long-running processes consuming from queues or doing batch processing
• Container Apps Jobs — Scheduled, event-triggered, or manual batch/cron workloads
• Any app stack — All languages, frameworks, and SDKs that run in a container

---

Gap-3: Container Apps Operate (C → A)

Learning from: App Service (B+) — deployment slots docs, scaling docs; Functions — azure-upgrade skill with Consumption→Flex automation

Current state: Scaling reference exists but no revision management guidance, no upgrade paths documented, no day-2 operations playbook.

Deliverables:

• services/container-apps/revisions.md — Revision management, traffic splitting, rollback patterns
• services/container-apps/day2-operations.md — Restart, exec into container, log streaming, environment variable updates
• services/container-apps/networking.md — VNet integration, internal/external ingress, custom domains, TLS
• services/container-apps/upgrade-paths.md — Single revision → multiple revision mode, environment SKU changes, Consumption → Dedicated
• Extend azure-upgrade skill to support Container Apps scenarios (or document as out-of-scope with rationale)
• Add 2 integration tests for Container Apps operate scenarios (revision management, scaling rules)

Key scenarios:

• Blue/green deployments via revision traffic splitting
• Canary releases with percentage-based traffic routing
• Rolling back to previous revision on failure
• Scaling rules for HTTP, Service Bus, custom metrics

---

Gap-4: Functions Operate (B → A)

Learning from: App Service (B+) — deployment slots docs cover the slot lifecycle well

Current state: azure-upgrade skill covers Consumption→Flex. Missing: slot management guidance for Premium/Dedicated, scaling best practices across hosting plans, cold start mitigation playbook.

Deliverables:

• services/functions/hosting-plans.md — Comparison matrix: Consumption vs Flex Consumption vs Premium vs Dedicated vs Container Apps, with decision criteria
• services/functions/cold-start.md — Cold start mitigation strategies per plan (pre-warmed instances, always-ready, Flex minimum instances)
• services/functions/slots.md — Deployment slot usage for Premium/Dedicated plans, slot-sticky settings, swap best practices
• Extend azure-upgrade to cover Premium→Flex, Dedicated→Flex paths
• Add 1 integration test for Functions slot/swap scenario

Key scenarios:

• Choosing the right hosting plan for workload characteristics
• Eliminating cold starts for latency-sensitive workloads
• Zero-downtime deployments with staging slots

---

Gap-5: App Service Operate (B+ → A)

Learning from: Functions — azure-upgrade skill with automated plan migration

Current state: Good deployment-slots and scaling references exist. Missing: automated upgrade path tooling, SKU right-sizing guidance, custom domain/TLS playbook.

Deliverables:

• services/app-service/sku-selection.md — SKU comparison matrix (Free→Basic→Standard→Premium→Isolated) with decision criteria and right-sizing guidance
• services/app-service/custom-domains.md — Custom domain + TLS certificate configuration via Bicep/Terraform
• services/app-service/networking.md — VNet integration, Private Endpoints, Access Restrictions, hybrid connections
• Extend azure-upgrade skill with App Service SKU upgrade paths (Free→Standard, Standard→Premium, etc.)
• Add 1 integration test for App Service operate (scaling or slot swap)

Key scenarios:

• Right-sizing SKU based on CPU/memory utilization metrics
• Custom domain with managed TLS certificate
• VNet integration for secure backend connectivity

---

Gap-6: App Service Diagnose (B → A)

Learning from: Container Apps (B+) — dedicated container-apps/README.md with specific troubleshooting flows for image pulls, cold starts, health probes

Current state: No dedicated App Service diagnostic reference. Falls back to general AppLens flow. Despite having the richest MCP tooling (7 commands), there's no guidance on when/how to use each.

Deliverables:

• references/app-service/README.md in azure-diagnostics — Dedicated troubleshooting guide covering:
  • High CPU/memory diagnosis (with specific AppLens detectors)
  • Deployment failure analysis (Kudu logs, deployment history API)
  • Application crash/restart diagnosis (Event Log, STDERR)
  • Slow response time investigation (request tracing, dependency analysis)
  • Custom domain / TLS certificate issues
• MCP tool usage guide — when to use each of the 7 App Service MCP commands for diagnostics
• Add 2 integration tests: deployment failure troubleshooting, high CPU diagnosis

Key scenarios:

• "My app is slow" → CPU profiler, request traces, dependency map
• "My deployment failed" → Kudu logs, SCM site, deployment history
• "My app keeps restarting" → event logs, health check failures, memory limits

---

Gap-7: Functions Diagnose (B → A)

Learning from: Container Apps (B+) — has both reference docs AND integration tests for diagnostics

Current state: Has dedicated functions/README.md reference with ARG queries for monitoring discovery. Missing: integration tests, trigger-specific troubleshooting, binding error diagnosis.

Deliverables:

• Extend references/functions/README.md with:
  • Trigger-specific troubleshooting (HTTP 5xx, timer misfires, queue poison messages, blob trigger delays)
  • Binding error diagnosis (connection string issues, permission errors, SDK version conflicts)
  • Durable Functions troubleshooting (stuck orchestrations, replay issues, task hub conflicts)
  • Flex Consumption-specific issues (instance allocation, networking)
• Add 2 integration tests: trigger failure diagnosis, binding error troubleshooting

Key scenarios:

• "My timer function isn't firing" → NCRONTAB validation, singleton lock, scale controller logs
• "My queue trigger has poison messages" → dead-letter analysis, maxDequeueCount config
• "My Durable orchestration is stuck" → task hub status, purge instance history

---

Gap-8: App Service Migrate — AWS Elastic Beanstalk → App Service (F → A)

Learning from: Functions Migrate (A) — 4-phase workflow (assess → migrate code → generate IaC → hand off), mandatory assessment report, 6 runtime guides, 12 service mappings

Current state: Zero coverage. No reference docs, no triggers, no tests.

Deliverables:

• references/services/app-service/beanstalk-to-app-service.md — Full migration guide:
  • Platform preset → App Service Plan SKU mapping
  • .ebextensions/ → Bicep/App Settings conversion
  • RDS → Azure SQL / Cosmos DB mapping
  • ALB → App Service built-in LB / Front Door
  • Environment variables → App Configuration / Key Vault
• references/services/app-service/heroku-to-app-service.md — Heroku migration guide:
  • Dynos → App Service instances
  • Procfile → Docker entrypoint / startup command
  • Add-ons → Azure managed services mapping
  • Buildpacks → Docker containers
• references/services/app-service/app-engine-to-app-service.md — GAE migration guide
• Runtime guides: runtimes/ for Python, Node.js, Java, .NET (App Service specifics)
• Assessment template for PaaS-to-PaaS migrations
• Add routing rules in azure-cloud-migrate SKILL.md for Beanstalk/Heroku/GAE keywords
• Add trigger tests for App Service migration prompts
• Add 1 integration test with a real Beanstalk sample app

Key service mappings:

AWS/Heroku/GCP	Azure App Service
Elastic Beanstalk Platform	App Service runtime stack
Heroku Dynos	App Service instances
App Engine Standard/Flex	App Service Plan Basic/Premium
.ebextensions/	Bicep + App Settings
Procfile	Startup command / Docker
RDS/Heroku Postgres	Azure SQL / PostgreSQL Flexible Server
ElastiCache/Redis add-on	Azure Cache for Redis
S3	Azure Blob Storage
CloudFront/Heroku edge	Azure Front Door / CDN

---

Gap-9: Container Apps Migrate — AWS ECS/Fargate + Cloud Run → Container Apps (F → A)

Learning from: Functions Migrate (A) — same 4-phase pattern, adapted for containers

Current state: Zero coverage. GCP mentioned in triggers only, no scenario guidance.

Deliverables:

• references/services/container-apps/ecs-to-container-apps.md — Full migration guide:
  • Task definitions → Container App YAML specs
  • Service definitions → Container App revisions + ingress
  • Fargate launch type → Consumption plan
  • ECR → ACR migration (image transfer)
  • ECS Service Connect → Container Apps service discovery
  • ALB/NLB routing → Container Apps ingress rules
  • App Mesh → Dapr integration
  • CloudWatch → Application Insights / Log Analytics
• references/services/container-apps/cloud-run-to-container-apps.md — GCP migration guide:
  • Cloud Run service/revision → Container App/revision (very similar model)
  • Artifact Registry → ACR
  • Cloud Run Jobs → Container Apps Jobs
  • Secret Manager → Key Vault
  • Concurrency settings → container concurrency config
• Container-specific assessment template (image analysis, port mapping, env vars, secrets, volumes)
• Add routing rules in azure-cloud-migrate for ECS/Fargate/Cloud Run keywords
• Add trigger tests for Container Apps migration prompts
• Add 1 integration test with a real ECS or Cloud Run sample app

Key service mappings:

AWS ECS/GCP Cloud Run	Azure Container Apps
Task Definition / Cloud Run YAML	Container App spec
Fargate / Cloud Run serverless	Consumption plan
ECR / Artifact Registry	Azure Container Registry
ECS Service Connect / Cloud Run svc	Container Apps service discovery
ALB / Cloud Run ingress	Container Apps ingress
App Mesh / Istio	Dapr
CloudWatch / Cloud Logging	App Insights + Log Analytics
ECS Exec / Cloud Run exec	Container Apps console
Task IAM / IAM SA	Managed Identity
KEDA (EKS) / min-instances	KEDA autoscaling

---

Gap-10: Container Apps Observe (B → A)

Learning from: App Service (A-) — has auto-instrumentation reference; Functions — has ARG query for monitoring discovery

Current state: Manual SDK instrumentation only. No auto-instrumentation. No monitoring discovery queries. No Container Apps-specific observability playbook.

Deliverables:

• references/container-apps/observability.md in appinsights-instrumentation — Container Apps-specific guide:
  • Environment-level Log Analytics workspace setup
  • System logs vs application logs distinction
  • Container Apps metrics (replica count, HTTP requests, CPU/memory per replica)
  • Distributed tracing across microservices with Dapr
• ARG queries for Container Apps monitoring discovery (find workspace, check instrumentation status)
• references/container-apps/dapr-observability.md — Dapr telemetry collection, tracing configuration
• Add dashboard/metrics guidance for Container Apps Environment-level monitoring
• Add 1 integration test for Container Apps observability setup verification

Key scenarios:

• "Are my Container Apps sending telemetry?" → ARG discovery query
• Distributed tracing across microservices with correlation IDs
• Dapr pub/sub and service invocation observability
• Container Apps Environment system logs vs app logs

---

Gap-11: Functions Observe (B → A)

Learning from: App Service (A-) — auto-instrumentation option

Current state: Manual SDK instrumentation, ARG queries for monitoring discovery exist. Missing: Functions-specific observability best practices, invocation-level tracing, Durable Functions monitoring.

Deliverables:

• references/functions/observability.md in appinsights-instrumentation — Functions-specific guide:
  • FunctionAppLogs table queries for invocation analysis
  • Invocation-level tracing (invocation ID, trigger details)
  • Durable Functions monitoring (orchestration status, activity timing)
  • Host-level vs function-level telemetry
• Built-in monitoring integration reference (Functions + App Insights auto-connection)
• KQL query library for common Functions diagnostics (error rate, duration P50/P95/P99, cold start frequency)
• Add 1 integration test for Functions observability setup

Key scenarios:

• Invocation duration analysis (P50/P95/P99 by function name)
• Cold start frequency tracking per hosting plan
• Durable Functions orchestration monitoring dashboard
• Scaling event correlation with performance metrics

---

Summary Table — All Gap Sub-Issues

Each row links to a sub-issue with full specifications. Implementation PRs will be opened against the pass-equity branch and will reference these issues.

[github-actions]

Thanks for the detailed write-up, @paulyuk! 🎯 This is a well-scoped enhancement request with clear success criteria and a phased implementation plan.

I've applied the following labels: enhancement (new feature/coverage expansion), azure-cloud-migrate (primary skill being extended), azure-prepare (routing rules need updating), and skills (cross-skill infrastructure work). The untriaged label has been removed.

The phased approach — starting with GCP serverless (Cloud Functions → Azure Functions) as the easiest win before tackling ECS/Fargate and PaaS migrations — looks well-reasoned. This is a meaningful body of work that would make Copilot for Azure the only AI tool offering guided cross-cloud migration across serverless, PaaS, and container workloads.

Generated by Issue Triage for issue #1608 · ◷