Projects

I built a sophisticated AI service orchestration system, then replaced it with text files. Sometimes the best solution is no solution.

The original system was a FastAPI router on Lightsail routing requests to Lambda functions. It worked. I used it. Then I found a simpler mental model for organizing AI context and rebuilt the whole thing as a flat directory structure with no infrastructure at all.

Before: 8 services, $21/month, 30-plus minutes to set up, 1-3 second response times. After: zero infrastructure, zero cost, under a minute to set up, under 50ms response.

Every CI/CD pipeline I inherited had the same problem: AWS access keys stored in GitHub secrets, rotation schedules nobody followed, and pipelines running with AdministratorAccess because scoping permissions was tedious.

I rebuilt my deployment infrastructure using GitHub Actions OIDC: short-lived tokens, no stored credentials, exact IAM permissions discovered through practical iteration. 100% elimination of stored secrets across three isolated environments, 15-minute token expiration, and a complete CloudWatch audit trail.

The interesting part was not the technical implementation. It was discovering the exact permissions required by actually running the pipeline and watching what failed. That is a discipline most teams skip by just granting broad access.

Event-driven pipelines built with custom retry logic and Lambda-to-Lambda calls get messy to debug. I wanted to see how Step Functions handled the orchestration layer instead.

The result is a distributed order fulfillment system where API Gateway receives orders, Step Functions coordinates validation and storage, and SQS handles fulfillment processing with automatic error recovery. Dead letter queues catch failures. The entire pipeline is defined as infrastructure code.

What I learned: Step Functions visual workflows are genuinely useful for debugging distributed systems, but the real value is in the built-in retry and error handling, not the visualization. The discipline of externalizing orchestration logic from your Lambda functions is worth adopting even when the tooling overhead feels steep.

I kept rebuilding the same infrastructure patterns for different projects. VPC setup, load balancers, ECS clusters, RDS databases. Copy-paste Terraform from old projects, spend hours debugging why it broke in the new environment.

This lab solves that problem with a modular framework that supports three compute platforms (EC2 Auto Scaling, ECS, EKS) behind the same networking and database modules. You can redeploy the same application architecture on a different compute platform by changing one variable.