Forem: Justin Wheeler

Part 2: From $68/month to $5/month - The "Lite" Deployment Strategy

Justin Wheeler — Sun, 02 Nov 2025 19:07:10 +0000

TL;DR

My Cloud Portfolio Challenge implementation costs $68 per month on Digital Ocean. I built a GitHub Pages "lite" version that costs just $5 per month (for DO Spaces + CDN) using the same codebase. Here's how feature flags and smart architecture let me showcase full capabilities on-demand while slashing ongoing costs by 92%, saving over $750 per year while maintaining full demo capabilities on-demand.

This post is part of my #CloudGuruChallenge series. It's a follow-up to "Better Late Than Never: Tackling the 2022 Cloud Portfolio Challenge" - showing how I reduced costs from $68/month to $5/month using the same codebase.

The Problem: When Reality Hits Your Wallet

Remember in Part 1 when I mentioned those DigitalOcean promotional credits? Yeah, they expired. And that feeling when you realize your portfolio project is costing you $68 per month to keep running? That's... not ideal.

Let's break down what I was paying for:

Load Balancer: $12 per month
2 Droplets (full-stack servers): $18 per month each = $36 per month
Valkey Database: $15 per month
DO Spaces + CDN: $5 per month

Total: $68 per month for a portfolio project that might get viewed once a week during interview seasons.

That's when I had a thought: What if I could keep the impressive architecture for demos but run at minimal cost 99% of the time?

The Solution: GitHub Pages "Lite" Mode

Enter the dual-deployment strategy. Same codebase, two completely different deployment targets:

Full Deployment (Digital Ocean): All the bells and whistles - AI generation, live voting, cross-session tracking
Lite Deployment (GitHub Pages): Static site with gracefully degraded features - local voting, pre-generated images

The magic? Feature flags that configure everything at build time.

The Architecture Decision

Instead of maintaining two separate codebases (nightmare fuel), I built a feature flag system that lets Next.js adapt based on NEXT_PUBLIC_DEPLOYMENT_MODE:

Full Mode (frontend/.env.full):

NEXT_PUBLIC_DEPLOYMENT_MODE=full
NEXT_PUBLIC_API_URL=https://api.wheeleraiduel.online
NEXT_PUBLIC_USE_STATIC_DATA=false

Lite Mode (frontend/.env.lite):

NEXT_PUBLIC_DEPLOYMENT_MODE=lite
NEXT_PUBLIC_API_URL=
NEXT_PUBLIC_USE_STATIC_DATA=true

The frontend reads these flags and swaps out implementations:

// frontend/app/services/dataService.ts
export const dataService = config.useStaticData
  ? staticDataService  // Reads from JSON files
  : apiDataService;    // Calls backend API

Same React components, different data sources. Clean, testable, maintainable.

Why Cost-Conscious Matters

Here's the thing about cloud deployments: they're running 24/7 whether you're using them or not. My project gets meaningful traffic maybe 2-3 days a month during demo calls or when I share it on LinkedIn.

Old strategy: Pay $68 per month regardless of usage

New strategy: Pay $5 per month baseline + demo costs only when needed

The only ongoing cost: $5 per month for DO Spaces + CDN (stores all images)
GitHub Pages hosting: $0 per month (completely free)
Full infrastructure: Only spin up for demos (~$2-3 per day, prorated hourly)

That's a 92% monthly cost reduction ($68 → $5) while maintaining the ability to showcase full capabilities when it matters.

Why keep DO Spaces? Both deployments need the images anyway. Spaces serves as the single source of truth with built-in CDN, so it's worth the $5 whether I'm running full or lite mode.

Annual math: Base cost of $60/year ($5 × 12 months) plus occasional demo costs. Even with 10-15 demo days per year, you're looking at ~$90-120/year instead of $816/year.

The GitHub Actions Workflow

The cheap-deploy.yml workflow is beautifully simple:

name: Deploy to GitHub Pages (Lite)

on:
  workflow_dispatch:

jobs:
  build:
    name: Build Lite Frontend
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '18'

    - name: Generate static data from DO Spaces
      run: |
        echo "📡 Fetching real image pairs from DO Spaces..."
        node .github/scripts/generate-static-data.js

    - name: Install frontend dependencies
      working-directory: frontend
      run: npm ci

    - name: Build frontend in lite mode
      working-directory: frontend
      run: npm run build:lite

    - name: Upload artifact
      uses: actions/upload-pages-artifact@v3
      with:
        path: frontend/out

  deploy:
    name: Deploy to GitHub Pages
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build

    steps:
    - name: Deploy to GitHub Pages
      id: deployment
      uses: actions/deploy-pages@v4

Key insight: The static data is generated automatically from DO Spaces. I don't manually maintain two sets of images. The build script fetches metadata from my DO Spaces bucket (which I keep running at $5 per month for the CDN anyway) and generates the image-pairs.json file at build time.

The Demo-Ready Strategy

Here's my actual workflow when I have an interview or want to showcase the full project:

Before the demo (20 minutes):

# 1. Deploy full infrastructure
Actions → pricy-deploy.yml → Run workflow (droplet_count: 2)

# 2. Wait ~8 minutes for deployment

# 3. Switch DNS to Digital Ocean
Actions → dns-cutover.yml → Run workflow (target: digital-ocean)

# 4. Wait 5-10 minutes for DNS propagation

After the demo (5 minutes):

# 1. Switch DNS back to GitHub Pages
Actions → dns-cutover.yml → Run workflow (target: github-pages)

# 2. Tear down all DO infrastructure
Actions → pricy-teardown.yml → Run workflow (confirm: DELETE PRICY)

Two quick workflows, and you're back to the $5/month baseline. The whole demo cycle costs about $2-3 (hourly prorated billing), and I can repeat this as many times as needed.

What You Lose (and What You Don't)

Features removed in lite mode:

❌ AI image generation
❌ Cross-session vote tracking
❌ Live statistics across users
❌ Backend API

Features preserved in lite mode:

✅ Same UI/UX
✅ Local voting (localStorage)
✅ Real images from DO Spaces CDN
✅ Mobile-optimized swipe interface
✅ Winners tracking (per browser)

For a portfolio project, the lite version is perfectly sufficient 95% of the time. Nobody really needs to generate new AI images when browsing my portfolio at 2am. They just need to see that the project works and looks professional.

Production-Grade Practices (The Real Portfolio Value)

Here's what this dual-deployment strategy demonstrates to recruiters:

1. Feature Flags & Configuration Management

Build-time feature flags allow a single codebase to serve multiple deployment targets. This is how real companies handle staging/production differences.

2. Blue/Green Deployment

Both deployments run simultaneously. I can test the lite version independently before cutting over DNS. Zero-downtime switching between environments.

3. Cost Optimization

Understanding cloud economics and implementing strategies to minimize costs while maintaining capabilities shows business acumen, not just technical skills.

4. Infrastructure as Code

The full deployment uses Pulumi. The lite deployment uses GitHub Actions. Both are reproducible, version-controlled, and automated.

5. Graceful Degradation

The frontend adapts intelligently to available backend services. This is critical for resilient production systems.

The Numbers

Metric	Full (DO)	Lite (GH Pages + DO Spaces)
Monthly Cost	$68	$5
Monthly Savings	-	$63 (92% reduction)
Build Time	~20 min	~3 min
Features	100%	~70%
Annual Base Cost	$816 per year	$60 per year*
Demo Cost	Included	+$2-3 per demo day

*Plus demo costs if/when you spin up full infrastructure

Was It Worth It?

Absolutely. I now have:

✅ A $5 per month portfolio deployment running 24/7
✅ Full feature showcase available on-demand
✅ Real-world experience with feature flags
✅ Blue/green deployment practice
✅ Cost optimization case study for interviews

And I'm saving $63 per month (92% reduction) while maintaining the ability to demonstrate the full project during interviews.

The Challenge: Your Turn

Think this approach could work for your cloud portfolio project? The patterns here apply to any dual-deployment scenario:

Full vs. lite
Production vs. preview
US region vs. EU region
Premium features vs. free tier

The 2022 Cloud Portfolio Challenge is still out there, still relevant in 2025. And now you have a cost-effective strategy for keeping it running without breaking the bank.

Connect & Build

Want to discuss cloud architecture, cost optimization strategies, or your own portfolio projects? Find me on LinkedIn - I'm always happy to connect with fellow builders.

Or better yet: Attempt the challenge yourself. Build something, deploy it two ways, and show recruiters you understand both technical excellence and business value. That's the real portfolio flex.

Repository: github.com/wheeleruniverse/cgc-lb-and-cdn

Better Late Than Never: Tackling the 2022 Cloud Portfolio Challenge in 2025 (With a Modern Twist)

Justin Wheeler — Mon, 20 Oct 2025 19:26:28 +0000

Connect with me: LinkedIn
Support my work: Buy me a coffee ☕

You know that feeling when you add something to your to-do list with every intention of knocking it out quickly... and then three years pass? Yeah, me too.

Back in June 2022, Lars Klint posted the Cloud Portfolio Challenge: Load Balancing and Content Delivery Network on Pluralsight. The challenge was straightforward: build an image delivery service that returns images matching search criteria, while learning about load balancing, CDN, compute, and storage fundamentals.

I bookmarked it. Added it to my list. And promptly let life happen.

Fast forward to October 2025, and I finally dusted off that bookmark. But here's the thing—I wouldn't have been able to build what I built if I had actually met that 2022 deadline. The tech stack I used simply didn't exist back then, or wasn't mature enough to use effectively.

So this is my "better late than never" submission, powered by 2025's tech stack, and honestly? I'm glad I waited.

The Original Challenge (And How I Completely Reimagined It)

The original challenge asked participants to build an image delivery service with four key cloud components:

Compute - Running the application logic
Storage - Storing and serving images
Load Balancing - Distributing traffic across instances
CDN - Delivering content globally with low latency

Simple enough, right? Well, I decided to add a twist: What if the images were AI-generated from a curated set of prompts, and users could vote on which images they prefer in head-to-head battles?

Enter: AI Image Battle Arena 🥊

Instead of serving pre-existing images, my application:

Asynchronously generates images using multiple AI providers (Freepik, Google Imagen, Leonardo AI) via scheduled cron jobs
Presents two random images side-by-side for comparison (both from the same provider to ensure fair comparison)
Lets users vote on which image they prefer via swipe gestures
Tracks statistics and winners in a Valkey (Redis-compatible) database
Serves everything through a CDN with load-balanced full-stack droplets

It's like Hot or Not, but for AI-generated art. Each comparison uses images from a single provider to keep things fair—I didn't want the user experience depending on multiple AI APIs being available simultaneously. This makes the system more resilient with ADK managing provider selection behind the scenes.

Why Digital Ocean? (A Love Letter to Simplicity)

Let me be upfront: I'm a major cloud provider person. I'm an AWS Community Builder, AWS User Group Leader, and AWS Gold Jacket holder. I've worked extensively with AWS, Azure, and GCP for years—and I genuinely love these platforms. They power the world's largest applications, and their breadth of services is unmatched.

(Sidebar: Yes, even with today's AWS outage on October 20, 2025—because let's be real, all cloud providers have bad days. The big three have earned their reliability reputations.)

But I kept hearing from other developers in the community: "You should try Digital Ocean. It's so much simpler. The developer experience is amazing."

And you know what? They were right.

After years with the hyperscalers, Digital Ocean felt like a breath of fresh air. The UI is clean, intuitive, and doesn't make you feel like you need a map just to find what you're looking for. Everything is straightforward—no endless service catalogs, no decision paralysis about which of the 17 database options to choose.

Some highlights from my DO experience:

1. Managed Databases (Valkey)

Setting up a Valkey cluster (Redis-compatible) via Pulumi was incredibly straightforward. The API is intuitive—just specify size, region, and VPC attachment. No complex subnet CIDR calculations or security group wizardry. It just works.

2. Spaces + CDN

Digital Ocean Spaces (S3-compatible object storage) comes with built-in CDN. Not "you need to set up CloudFront and configure origins and behaviors"—it's just... included. Upload your images, they're automatically CDN-distributed. Chef's kiss. 👌

3. DO Metrics Agent

Here's a cool feature I didn't expect: Digital Ocean offers an enhanced metrics agent you can install on droplets that measures things like memory usage—metrics that aren't included in the free tier on other providers. I configured it in my UserData script, and suddenly I had deep observability into my droplet performance without additional cost.

4. Credits and Support

DO gave me $200 in promotional credits (60-day expiration) to test things out. And when I had questions about Droplet limits? Their support team responded quickly with helpful, non-robotic answers.

To be clear: AWS, Azure, and GCP are incredible platforms that I'll continue using for enterprise work. But for side projects, learning, and rapid prototyping? Digital Ocean's simplicity is genuinely refreshing. Different tools for different jobs.

5. Domain Management with Namecheap + DO Nameservers

For this project, I grabbed a domain from Namecheap: wheeleraiduel.online for just $0.98/year. Since this is a side project I don't plan to keep live beyond a year, why spend $12+ on a .com?

The setup is beautifully simple:

Register domain on Namecheap (~$1)
Point Namecheap to Digital Ocean's nameservers
Manage all DNS records directly in the DO console
Let's Encrypt SSL certificates auto-provision via Pulumi

This hybrid approach gives me Namecheap's pricing with DO's DNS management UX. Best of both worlds for a temporary project.

Why Random Prompts? (Safety First)

You might notice the application generates images from a curated set of prompts rather than taking user input. This was a deliberate design choice for three reasons:

1. Async Generation Architecture

Since images are generated via scheduled cron jobs (not on-demand), there's no user session to capture input from. The generation happens in the background, building up a library of images that the frontend randomly serves.

2. User Input Requires Special Care

Accepting user input means:

Input validation and sanitization
Rate limiting to prevent abuse
Moderation to filter inappropriate prompts
Storage and management of user data
Potential GDPR/privacy concerns

For a side project focused on cloud architecture and AI orchestration? That's scope creep I didn't need.

3. Prompt Injection Is Real

Generative AI is susceptible to prompt injection attacks where malicious users craft inputs to bypass safety filters or generate harmful content. By using a curated set of prompts (generated by Claude and Gemini during development), I completely eliminate this attack vector.

Example curated prompts:

"Robot holding a red skateboard"
"Astronaut riding a bicycle on the moon"
"Cat wearing sunglasses at a coffee shop"

Safe, fun, and focused on the technical infrastructure—not content moderation.

The Tech Stack That Made This Possible

Here's where 2025 tech really shines:

Backend: Go + Gin Framework

I built the API server in Go using the Gin web framework. Why Go? Fast, statically typed, great concurrency support, and perfect for cloud-native applications. The backend handles:

Image generation orchestration
Provider fallback logic
Vote tracking and statistics
Health checks for the load balancer

Frontend: Next.js 14

The image comparison interface is built with Next.js, featuring:

Mobile-first responsive design with swipe gestures
Framer Motion animations with spring physics
Real-time vote feedback
Server-side rendering for SEO

Infrastructure as Code: Pulumi (with Go)

I've used Terraform extensively, and I've worked with CloudFormation and AWS CDK. But for this project, I went with Pulumi—and I'm genuinely impressed.

Pulumi lets you write infrastructure code in real programming languages (I used Go for consistency with my backend). No HCL to learn, no YAML templating gymnastics—just actual code with real loops, conditionals, and type safety.

Here's what my infrastructure deploys:

// Simplified example from hosting/main.go
droplets := make([]*digitalocean.Droplet, dropletCount)
for i := 0; i < dropletCount; i++ {
    droplet, err := digitalocean.NewDroplet(ctx, logicalName, &digitalocean.DropletArgs{
        Name:     pulumi.String(physicalName),
        Image:    pulumi.String("ubuntu-22-04-x64"),
        Size:     pulumi.String("s-2vcpu-2gb"),
        Region:   pulumi.String("nyc3"),
        VpcUuid:  vpc.ID(),
        UserData: getFullStackUserData(config),
    })
    droplets[i] = droplet
}

Each droplet runs:

Backend Go API server (port 8080)
Frontend Next.js app (port 3000)
Nginx reverse proxy (port 80)
Automated log uploads to Spaces (hourly, gzip compressed)
DigitalOcean metrics agent

The Pulumi console gives you real-time visibility into deployments:

Why Pulumi over Terraform? A few reasons:

Type Safety: Compiler catches errors before deployment
Loops & Logic: Native language constructs instead of count hacks
Single Language: Same language as my backend (Go)
Better Error Messages: Actually tells you what's wrong

Pulumi might not have Terraform's community size yet, but for greenfield projects, it's a compelling choice.

Google Agent Development Kit (ADK)

Here's the real 2025 magic: Google's Agent Development Kit.

I learned about ADK from my connection Kelby Enevold, who told me how cool it was. ADK is Google's framework for building AI agents that can orchestrate tasks, use tools, and handle complex workflows.

In my application, ADK powers the "orchestrator agent" that:

Randomly selects an AI image provider
Calls the provider's API to generate an image
Detects quota limits, rate limits, or errors
Automatically falls back to a different provider
Handles retries and error scenarios

This pattern—intelligent provider selection with automatic fallback—would have been manual spaghetti code without ADK. Instead, it's a clean agent-based architecture that "just works."

This literally wouldn't have been possible in 2022. Google ADK was announced at Google Cloud Next 2025, with the stable Python v1.0.0 release happening in 2024. It's built on the same foundation powering Google's own products like Agentspace and their Customer Engagement Suite.

Hot Storage vs. Cold Storage: Why Valkey Is Optional

One architectural decision I'm particularly proud of: Digital Ocean Spaces is my single source of truth.

Here's how the data architecture works:

Cold Storage: DO Spaces (Source of Truth)

Every generated image is stored in DO Spaces with rich metadata:

Image file: The actual PNG/JPEG
Object metadata:
- provider: Which AI service generated it (freepik, google-imagen, leonardo-ai)
- prompt: The text prompt used for generation
- Other generation details

This metadata lives directly on the S3-compatible object storage. No separate database required.

Hot Storage: Valkey (Performance Cache)

Valkey stores:

Vote counts and statistics
Side win tracking (left vs. right)
Winning image references
Real-time leaderboard data

But here's the key insight: Valkey is purely for performance. It's a cache, not the source of truth.

The `recreate_valkey` Flag

In my GitHub Actions deploy workflow, there's a boolean parameter called recreate_valkey. When set to true, it:

Scans all objects in DO Spaces
Reads metadata from each image
Rebuilds Valkey indexes from scratch
Repopulates provider statistics

This means I can:

Delete the entire Valkey cluster to save costs
Recover from Valkey data corruption
Rebuild after accidental data loss
Migrate to a different caching solution

The images, prompts, and generation history are never lost. They live permanently in Spaces.

Why This Matters

Many applications tightly couple their database and storage layers. If the database fails, critical metadata is gone forever. By storing metadata with the objects themselves, I've created a resilient architecture where:

Valkey failure = temporary performance degradation, not data loss
Spaces backup = complete system backup, including all metadata
Cost optimization = optional caching layer when budget is tight

For the "lite" version I'm planning in Part 2, I could potentially run without Valkey entirely—serving slightly slower but still functional. That's architectural flexibility.

The Build Process: Research First, Deploy Last

People sometimes ask me: "How do you even start large side projects like this?"

My answer: Start small. Start with research.

Here's how I structured this project:

Phase 1: Research (`research/` directory)

Before writing a single line of business logic, I created small Proof of Concepts for each AI provider:

research/
├── freepik/          # Test Freepik API integration
├── google-imagen/    # Test Google Imagen API
├── leonardo-ai/      # Test Leonardo AI API
└── craiyon/          # Test Craiyon (spoiler: broken)

Each research folder had its own README documenting:

How to authenticate
How to make requests
Response formats
Pricing/quota limits
Gotchas and workarounds

This meant when I started building the actual backend, I wasn't debugging API integration issues—I already knew exactly how each provider worked.

Key lesson: Spend time in research mode. It pays dividends later.

Phase 2: Backend (`backend/`)

Once I understood the providers, I built the Go API server:

Provider abstraction layer
ADK orchestrator integration
Valkey vote tracking
Image storage to DO Spaces

Phase 3: Frontend (`frontend/`)

Next.js app with mobile-optimized voting interface:

Swipe left/right to vote
Real-time animations
Statistics display

Phase 4: Infrastructure (`hosting/`)

Last step: Deploy to the cloud.

Why last? Because cloud providers bill you from the moment you provision resources. By building locally first, I:

Avoided weeks of unnecessary billing
Used my DO credits efficiently (60-day expiration)
Deployed a complete, tested application—not a half-baked experiment

This order—research → backend → frontend → hosting—is how I approach every side project. It keeps costs down and reduces cloud debugging headaches.

GitHub Actions: The Full Deployment Pipeline

Once infrastructure code was ready, I built three GitHub Actions workflows to manage everything:

1. Deploy Workflow

One-click deployment via GitHub Actions:

Provisions all infrastructure (load balancer, droplets, database, CDN)
Configurable droplet count (2-10 instances)
Auto-deploys applications via UserData script
Sets up monitoring and log shipping

2. Teardown Workflow

Safe infrastructure destruction:

Requires typing "DESTROY" to confirm (safety first!)
Cleans up auto-created DNS records
Removes all resources to stop billing
Saves ~$68/month when not in use

3. Refresh Workflow

State synchronization:

Syncs Pulumi state with actual cloud resources
Useful after manual changes in DO console
Detects and resolves state drift

Full transparency: This automation is a game-changer. Push code, watch it deploy, tear it down when done. No manual server configuration, no SSH debugging sessions.

What I Learned (And What Surprised Me)

1. Simplicity Has Value

AWS's breadth of services is powerful, but DO's focused simplicity meant I spent more time building features and less time reading documentation about VPC peering topologies.

2. IaC Language Matters

Using Go for both backend and infrastructure code created a cohesive developer experience. Context switching between languages is mentally taxing—Pulumi eliminated that.

3. AI Agents Are Production-Ready

Google ADK isn't just a toy—it handles real production workflows with fallback logic, error handling, and reliability. This is the future of orchestration.

4. UserData Is Underrated

My droplets auto-deploy everything via UserData scripts:

Install dependencies (Go, Node.js, nginx)
Clone and build applications
Configure systemd services
Set up cron jobs for log uploads
Install monitoring agents

No manual SSH configuration. No Ansible playbooks. Just boot and go.

5. Research Time Is Never Wasted

Those small POCs in the research/ folder saved me countless debugging hours later. Investing in understanding your dependencies upfront is time well spent.

The Challenge Requirement Checklist ✅

So, did I actually complete the original challenge requirements?

✅ Compute: Full-stack droplets running Go + Next.js + nginx
✅ Storage: DO Spaces for images and logs
✅ Load Balancing: DO Load Balancer distributing traffic across instances
✅ CDN: Built-in CDN via DO Spaces
✅ Image Delivery: Returns images (AI-generated) matching search criteria
✅ Learning Outcome: Deep understanding of how these components work together

Bonus achievements:

✅ Infrastructure as Code (Pulumi)
✅ AI orchestration (Google ADK)
✅ Automated deployment (GitHub Actions)
✅ Production-grade monitoring (DO Metrics Agent)
✅ Security hardening (non-root service user, VPC-isolated database)
✅ Cost optimization (automated teardown, log compression)

Final Thoughts: Better Late Than Never

Did I miss the 2022 deadline? Absolutely.

Do I regret waiting? Not even a little.

This project showcases technology that didn't exist three years ago:

Google ADK for AI orchestration (released 2024)
Modern generative AI APIs (Imagen 3.0, Leonardo AI)
Pulumi's matured Go SDK
Next.js 14's App Router
Digital Ocean's enhanced features

Sometimes the best time to tackle a challenge is when you have the right tools for the job.

If you're sitting on a dusty to-do item from years ago, consider this your sign: maybe now is actually the perfect time. The tools have gotten better. Your skills have improved. And that "overdue" project might turn into your best work yet.

Thanks to Lars Klint for the original challenge, Kelby Enevold for introducing me to Google ADK, and the Digital Ocean team for making cloud infrastructure genuinely enjoyable to work with.

What's Next? Stay Tuned for Part 2 📅

As my DO promotional credits approach expiration near the end of the year, I'm planning to deploy a "lite" version of this project—a cost-optimized configuration designed to avoid bill shock while keeping the core functionality intact.

Part 2 will cover:

Cost optimization strategies for production
Scaling down gracefully without losing features
Balancing cloud costs vs. capabilities
Real-world lessons from running AI infrastructure on a budget

Follow me on LinkedIn to catch Part 2 when it drops!

Want to Build This Yourself?

The entire project is open source on GitHub:

Repository: wheeleruniverse/cgc-lb-and-cdn
Live Demo: wheeleraiduel.online (when deployed)

The README includes:

Complete setup instructions
Architecture diagrams
API documentation
Cost breakdowns
Deployment guides

Give it a star if you found this interesting, and feel free to fork it for your own experiments!

What cloud challenges are sitting on your dusty to-do list? Drop them in the comments—let's hold each other accountable! 👇

Enjoyed this post? Buy me a coffee ☕ to support more cloud adventures!

Conquering the Multi-Cloud Resume Challenge: My Journey to a Serverless Showcase

Justin Wheeler — Wed, 23 Jul 2025 19:20:18 +0000

The Challenge: Beyond a Single Cloud
My Multicloud Resume: A Deep Dive
- The Architecture: Think Globally, Deploy Remotely
- Cloud Provider Implementation: A Complexity Comparison
- The Stack: Tried, Tested, and True
Technical Deep Dive: Cloud-Agnostic Business Logic
- Database Connector Complexity Analysis
- Multi-Cloud Environment Configuration
- CI/CD: The Automated Dream
- Features that Impress
Performance/Cost Analysis: The Real-World Impact
- Cold Start Performance Analysis
- Deployment Speed Comparison
- Cost Analysis: Monthly Operating Expenses
- Performance Optimization Insights
- Key Takeaways
Gotchas and Pain Points: The Multi-Cloud Reality Check
- Azure's SKU-Based Pricing: The Feature Wall
- HTTP to HTTPS Redirect: Azure's Hidden Cost
- Database Consistency Models: The Hidden Complexity
- Container Registry Complexity
- Authentication and Secrets Management
- Monitoring and Debugging Differences
- SKU Upgrade Pressure: The Azure Tax
- Lessons Learned: Multi-Cloud Gotchas
- The Bottom Line
What I Learned (and Why You Should Try It!)

Hey there, fellow cloud enthusiasts! You know that feeling when a new challenge lands in your lap, and it just clicks with everything you've been working towards? That's exactly how I felt when I stumbled upon the Meta Resume Challenge. It wasn't just another cloud project; it was an opportunity to truly flex those multi-cloud muscles and build something that screams "enterprise-level cloud development!"

The Challenge: Beyond a Single Cloud

Forrest Brazeal's original Cloud Resume Challenge was a game-changer, pushing us to build a serverless resume on a single cloud. But what if you could take that concept and multiply it by three? That's the essence of the Meta Resume Challenge: constructing a comprehensive, serverless resume application deployed across AWS, Azure, and Google Cloud Platform, each with complete isolation.

This wasn't just about putting a resume online; it was about demonstrating proficiency in:

Three-tier architecture: Frontend, backend, and database.
Serverless everywhere: Functions, Lambda, Cloud Run – you name it.
Infrastructure as Code (IaC): Because who wants to click around consoles anymore?
CI/CD pipelines: Automating the build, test, and deployment dance.
Cloud-agnostic skills: Building solutions that aren't locked into a single provider.

My Multicloud Resume: A Deep Dive

My approach to the Meta Resume Challenge is encapsulated in my Multicloud Resume GitHub repository. I aimed for a robust, production-ready application that showcases not just what I know, but how I build.

The Architecture: Think Globally, Deploy Remotely

At its core, my solution is a classic three-tier serverless application. But here's the kicker: each tier is strategically deployed across the three major cloud providers.

Frontend (Angular) ──► API Gateway ──► Serverless Functions ──► Cloud Databases
     │                          │                     │                       │
Static Web                Load Balancer         Business Logic          Data Storage
(CDN + Storage)                               (Spring Boot)           (NoSQL DBs)

Here's how the components are distributed across the clouds:

Component	AWS	Azure	GCP
Frontend	CloudFront + S3	Static Web Apps	Cloud Storage + CDN
API	API Gateway + Lambda	Function App	Cloud Run
Database	DynamoDB	Cosmos DB	Firestore
Storage	S3 Buckets	Blob Storage	Cloud Storage
CDN	CloudFront	Front Door	Cloud CDN

Cloud Provider Implementation: A Complexity Comparison

After examining the serverless implementations across all three providers, here's what I discovered about their technical approaches:

🥇 Simplest: Google Cloud Platform

GCP's Cloud Run approach is the most developer-friendly—it's just a standard Spring Boot application:

@SpringBootApplication
public class Main {
    public static void main(String[] args){
        SpringApplication.run(Main.class, args);
    }
}

No special handlers, no cloud-specific annotations, just SpringApplication.run(). This makes local development and testing seamless.

🥈 Most AWS-Specific: Amazon Web Services

AWS Lambda requires the SpringBootLambdaContainerHandler pattern, adding an abstraction layer between your Spring Boot app and Lambda runtime:

public class LambdaHandler implements RequestStreamHandler {
    private static final SpringBootLambdaContainerHandler<AwsProxyRequest, AwsProxyResponse> HANDLER;

    static {
        try {
            HANDLER = SpringBootLambdaContainerHandler.getAwsProxyHandler(Main.class);
        } catch (ContainerInitializationException e) {
            throw new RuntimeException("StreamHandler ContainerInitializationException", e);
        }
    }

    @Override
    public void handleRequest(InputStream inputStream, OutputStream outputStream, Context context) throws IOException {
        HANDLER.proxyStream(inputStream, outputStream, context);
        outputStream.close();
    }
}

While more complex than GCP, it's still relatively clean and provides good integration with the AWS ecosystem.

🥉 Most Verbose: Microsoft Azure

Azure Functions demands the most ceremony—individual @FunctionName annotations for each endpoint, cloud-specific types, and manual response building:

@FunctionName("visitorCount")
public HttpResponseMessage count(
        @HttpTrigger(
                authLevel = AuthorizationLevel.ANONYMOUS,
                methods = {HttpMethod.GET},
                route = "visitor/count")
                HttpRequestMessage<Void> request,
        final ExecutionContext context) {

    try {
        final Count data = handleRequest(Optional.empty(), context);
        context.getLogger().info(String.format("received %d as the visitor count", data.getValue()));
        return request.createResponseBuilder(HttpStatus.valueOf(200)).body(new CountDto(data)).build();
    } catch(Exception e) {
        return new ExceptionHandler(context, e, request).asHttpResponse();
    }
}

However, this verbosity provides fine-grained control over function behavior and excellent integration with Azure's monitoring and logging.

The Stack: Tried, Tested, and True

I leveraged a technology stack that's both modern and enterprise-friendly:

Backend: Java 11 with Spring Boot 2.5.4, Spring Cloud Function for serverless compatibility, and robust testing with JUnit 5 and Mockito.
Frontend: Angular 11 with TypeScript, NgRx for state management, and Angular Material for a sleek UI.
Infrastructure: Terraform for all IaC needs, with GitHub Actions orchestrating the entire CI/CD pipeline. Docker plays a key role for containerization.

State Management with NgRx

The frontend leverages NgRx for sophisticated state management, handling complex async operations like visitor tracking:

count$: Observable<Action> = createEffect(() => {
  return this.actions$.pipe(
    ofType<VisitorCountAction>(VisitorActionType.Count),
    switchMap(() => {
      return this.visitorService.count().pipe(
        map((state) => new VisitorCountSuccessAction(state)),
        catchError((error) => of(new ErrorAction(error)))
      );
    })
  );
});

incrementSuccess$: Observable<Action> = createEffect(
  () => {
    return this.actions$.pipe(
      ofType<VisitorIncrementSuccessAction>(VisitorActionType.IncrementSuccess),
      tap(() => {
        this.cookieService.set(this.cookie, 'true', 30);
        this.snackBar.open('New Visitor Success!', null, this.snackBarConfig);
      })
    );
  },
  { dispatch: false }
);

This reactive approach ensures consistent user experience regardless of which cloud provider is serving the request.

Technical Deep Dive: Cloud-Agnostic Business Logic

One of the most elegant aspects of this architecture is how Spring Cloud Function enables identical business logic across all three clouds:

@Service
public class VisitorService {
    private final CountRepository visitorRepository;

    @Bean
    public Function<Optional<?>, Count> visitorCount() {
        return (o) -> visitorRepository.count();
    }

    @Bean  
    public Function<Optional<?>, Optional<?>> visitorIncrement() {
        return (o) -> {
            visitorRepository.increment();
            return Optional.empty();
        };
    }

    @Bean
    public Function<Integer, Optional<?>> visitorLoad() {
        return (value) -> {
            validateCount(value);
            visitorRepository.load(value);
            return Optional.empty();
        };
    }
}

This functional approach means the same business logic runs identically whether it's invoked by AWS Lambda, Azure Functions, or GCP Cloud Run.

Database Connector Complexity Analysis

The database connectivity reveals interesting differences in each cloud's SDK design philosophy:

AWS DynamoDB (Simplest):

public DynamoDbClient getClient(){
    if (this.client == null){
        this.client = DynamoDbClient.builder()
                .credentialsProvider(DefaultCredentialsProvider.create())
                .region(Region.of(region))
                .build();
    }
    return this.client;
}

Azure Cosmos DB (Medium Complexity):

public CosmosClient getClient() {
    if (client == null){
        client = new CosmosClientBuilder()
                .consistencyLevel(ConsistencyLevel.EVENTUAL)
                .endpoint(cosmosHost)
                .key(cosmosAuth)
                .buildClient();
    }
    return client;
}

GCP Firestore (Most Complex):

public FirestoreOptions getOptions() {
    if (options == null){
        options = FirestoreOptions.getDefaultInstance().toBuilder()
                .setProjectId(project)
                .setCredentials(getCredentials()) // Requires custom credential handling
                .build();
    }
    return options;
}

private Credentials getCredentials(){
    try(final InputStream credentialsStream = new ByteArrayInputStream(credentials.getBytes())){
        return GoogleCredentials.fromStream(credentialsStream);
    } catch(IOException e){
        throw new InternalServerErrorException("getCredentials() Failed");
    }
}

Multi-Cloud Environment Configuration

The Angular frontend uses environment-specific configurations to seamlessly switch between cloud providers:

// environment.aws.ts
export const environment = {
  backend: 'https://api.aws.wheelercloudguru.com',
  provider: 'aws',
  storage: 'https://wheelercloudguru-iac.s3.amazonaws.com/web'
};

// environment.azure.ts  
export const environment = {
  backend: 'https://wheelercloudguru.azurewebsites.net/api',
  provider: 'microsoft', 
  storage: 'https://wheelercloudguruiac.blob.core.windows.net/web'
};

// environment.gcp.ts
export const environment = {
  backend: 'https://api.gcp.wheelercloudguru.com',
  provider: 'google',
  storage: 'https://storage.googleapis.com/wheelercloudguru-iac/web'
};

The project structure is clean and modular, allowing for clear separation of concerns, from core business logic to cloud-specific implementations:

multicloud-resume/
├── app/                      # Backend applications
│   ├── core/                 # Shared business logic and models
│   ├── aws/                  # AWS Lambda implementation
│   ├── azure/                # Azure Functions implementation
│   └── gcp/                  # Google Cloud Run implementation
├── web/                      # Angular frontend application
├── iac/                      # Infrastructure as Code
│   ├── terraform/            # Terraform configurations
│   ├── data/                 # Resume data (JSON/Excel)
│   └── diagrams/             # Architecture diagrams
└── README.md

CI/CD: The Automated Dream

My favorite part? The comprehensive CI/CD pipeline built with GitHub Actions. Each cloud platform has its dedicated workflow, ensuring that every code push triggers automated builds, tests, and deployments:

app-core.yml: Builds and tests the shared core module.
app-aws.yml: Deploys AWS Lambda functions.
app-azure.yml: Deploys Azure Functions.
app-gcp.yml: Deploys GCP Cloud Run services.
web.yml: Builds and deploys the frontend to all platforms.

This setup ensures rapid, reliable deployments and keeps everything in sync.

Features that Impress

Beyond the core requirements, I added some features that really make the resume shine:

Real-time Visitor Counter: A fun touch that tracks visitors across all platforms.
Responsive Design: Optimized for every device.
Performance Optimization: CDN, caching, and compression for a lightning-fast experience.
Comprehensive Testing: Unit, integration, and end-to-end tests for both backend and frontend.

Performance/Cost Analysis: The Real-World Impact

One of the most valuable aspects of this multi-cloud implementation was gaining concrete insights into performance characteristics and cost implications across providers. Here's what the data revealed:

Cold Start Performance Analysis

Through extensive testing and monitoring, I discovered significant differences in serverless cold start times:

Provider	Cold Start Time	Warm Response	Memory Config
AWS Lambda	~2.8 seconds	~150ms	512MB
Azure Functions	~4.2 seconds	~200ms	Dynamic (Y1)
GCP Cloud Run	~1.5 seconds	~120ms	Default

GCP Cloud Run emerged as the performance winner, benefiting from its containerized approach and faster initialization. The standard Spring Boot deployment model eliminates the overhead of serverless-specific frameworks.

AWS Lambda showed consistent mid-range performance, with the SpringBootLambdaContainerHandler adding some initialization overhead but providing reliable execution.

Azure Functions had the longest cold starts, likely due to the Java runtime initialization and the multiple function bindings required for the individual endpoint approach.

Deployment Speed Comparison

The deployment characteristics varied significantly across platforms:

# AWS: Container-based deployment via ECR
resource "aws_lambda_function" "this" {
  function_name = var.domain
  image_uri     = "${var.account}.dkr.ecr.${var.region}.amazonaws.com/${var.domain}:${var.image}"
  memory_size   = 512
  timeout       = 30
}

# Azure: Dynamic consumption plan
resource "azurerm_app_service_plan" "this" {
  kind = "FunctionApp"
  sku {
    size = "Y1"
    tier = "Dynamic"
  }
}

# GCP: Direct container deployment
resource "google_cloud_run_service" "this" {
  template {
    spec {
      containers {
        image = var.image
      }
    }
  }
}

Deployment Speed Results:

GCP Cloud Run: ~2-3 minutes (fastest)
AWS Lambda: ~4-5 minutes (container build + deploy)
Azure Functions: ~6-8 minutes (dynamic scaling setup)

Cost Analysis: Monthly Operating Expenses

Based on my Terraform configurations and actual usage patterns, here's the cost breakdown for a low-traffic resume site (~1,000 monthly visitors):

AWS Infrastructure Costs:

# DynamoDB: Provisioned mode
resource "aws_dynamodb_table" "this" {
  billing_mode   = "PROVISIONED"
  read_capacity  = 1    # ~$0.65/month per table
  write_capacity = 1    # ~$0.65/month per table
}

# CloudFront: PriceClass_100 (US/Europe)
resource "aws_cloudfront_distribution" "this" {
  price_class = "PriceClass_100"  # ~$1.00/month for low traffic
}

AWS Total: ~$12-15/month

Lambda: $0 (within free tier)
DynamoDB: ~$8/month (6 tables × $1.30)
CloudFront: ~$1/month
S3 Storage: ~$1/month
API Gateway: ~$2/month

Azure Infrastructure Costs:

# Cosmos DB: Free tier enabled
resource "azurerm_cosmosdb_account" "this" {
  enable_free_tier = true
  capabilities {
    name = "EnableServerless"  # Pay-per-request
  }
}

Azure Total: ~$5-8/month

Functions: $0 (within free tier)
Cosmos DB: $0 (free tier covers usage)
CDN: ~$2/month
Storage: ~$3/month
Application Insights: ~$2/month

GCP Infrastructure Costs:

# Cloud Run: Pay-per-request, generous free tier
resource "google_cloud_run_service" "this" {
  # No minimum provisioning required
}

# Firestore: Native mode, free tier
# App Engine app required for Firestore
resource "google_app_engine_application" "this" {
  database_type = "CLOUD_FIRESTORE"
}

GCP Total: ~$3-5/month

Cloud Run: $0 (within free tier)
Firestore: $0 (free tier sufficient)
Cloud Storage: ~$1/month
CDN: ~$2/month

Performance Optimization Insights

The Terraform configurations reveal different optimization strategies:

AWS Optimization:

# Aggressive caching with CloudFront
default_cache_behavior {
  compress = true
  cached_methods = ["GET", "HEAD"]
  viewer_protocol_policy = "redirect-to-https"
}

Azure Optimization:

# Content-specific compression rules
resource "azurerm_cdn_endpoint" "this" {
  content_types_to_compress = [
    "application/javascript",
    "application/json",
    "text/css",
    "text/html"
  ]
  is_compression_enabled = true
}

GCP Optimization:

# Backend bucket with CDN
resource "google_compute_backend_bucket" "this" {
  enable_cdn = true  # Simple but effective
}

Key Takeaways

Most Cost-Effective: GCP wins with superior free tiers and serverless-first pricing
Best Performance: GCP Cloud Run's container approach provides fastest cold starts
Most Enterprise Features: Azure offers the richest monitoring and debugging capabilities
Most AWS-Native: Lambda integrates best with other AWS services but at higher cost

For a production multi-cloud strategy, I'd recommend:

Development/Testing: GCP (lowest cost, fastest iteration)
Production: AWS (ecosystem maturity, enterprise support)
Analytics/Monitoring: Azure (superior Application Insights integration)

Gotchas and Pain Points: The Multi-Cloud Reality Check

While building across three cloud providers was incredibly educational, it wasn't without its frustrations. Here are the real-world pain points that caught me off guard and could save you significant time and headaches:

Azure's SKU-Based Pricing: The Feature Wall

The most significant pain point was Azure's rigid SKU-based pricing model, which creates artificial feature limitations that simply don't exist on AWS or GCP.

The Custom Domain Dilemma

# Azure: Consumption plan limitations
resource "azurerm_app_service_plan" "this" {
  kind = "FunctionApp"
  sku {
    size = "Y1"      # Consumption tier
    tier = "Dynamic" # Locked into this for serverless
  }
}

# Result: NO custom domain support on consumption plan!
# You're forced to use: https://myapp.azurewebsites.net/api

The Problem: Azure's consumption plan (Y1 SKU) doesn't support custom domains, period. To get https://api.azure.mysite.com, you need to upgrade to a Premium plan (~$150/month minimum), completely defeating the serverless cost model.

AWS/GCP Reality Check:

# AWS: Custom domains included with API Gateway (free tier eligible)
resource "aws_apigatewayv2_api" "this" {
  # Works with custom domains out of the box
}

# GCP: Custom domains work seamlessly with Cloud Run  
resource "google_cloud_run_domain_mapping" "this" {
  name = "api.gcp.${var.fqdn}" # Just works, no SKU restrictions
}

Both AWS and GCP offer custom domain support as a standard feature, not a premium upgrade.

HTTP to HTTPS Redirect: Azure's Hidden Cost

Another Azure gotcha was the HTTP to HTTPS redirect functionality:

# Azure: Requires separate CDN endpoint for HTTPS redirect
resource "azurerm_cdn_endpoint" "this" {
  delivery_rule {
    name  = "HttpToHttpsRedirect"
    order = 1

    request_scheme_condition {
      match_values = ["HTTP"]
      operator     = "Equal"
    }
    url_redirect_action {
      protocol      = "Https"
      redirect_type = "PermanentRedirect"
    }
  }
}
# Additional monthly CDN costs just for HTTPS redirect!

Meanwhile on AWS/GCP:

# AWS CloudFront: HTTPS redirect built-in, free
viewer_protocol_policy = "redirect-to-https" # That's it!

# GCP: Automatic HTTPS redirect, no extra config needed

Database Consistency Models: The Hidden Complexity

Each cloud's NoSQL offering has different default consistency models that aren't immediately obvious:

# Azure: Must explicitly configure consistency
resource "azurerm_cosmosdb_account" "this" {
  consistency_policy {
    consistency_level = "Eventual" # Required explicit choice
  }
}

# AWS: Eventual consistency by default, no config needed
resource "aws_dynamodb_table" "this" {
  # Consistency is handled automatically
}

# GCP: Strong consistency by default
# Firestore handles this transparently

The Gotcha: I spent hours debugging what I thought were data sync issues, only to discover it was Azure Cosmos DB's default consistency settings interacting poorly with my test data.

Container Registry Complexity

The container registry setup revealed significant differences in approach:

# AWS: Simple ECR setup
resource "aws_ecr_repository" "this" {
  name = var.domain
  image_scanning_configuration {
    scan_on_push = true
  }
}

# Azure: No built-in container registry with Functions
# Must use Azure Container Registry (ACR) separately
# or Docker Hub - additional complexity and cost

# GCP: Container Registry built into the platform
resource "google_container_registry" "this" {
  location = var.location_multi_region
}

The Pain: Azure Functions don't have seamless container registry integration like AWS Lambda or GCP Cloud Run, forcing you into more complex deployment patterns.

Authentication and Secrets Management

Managing service account credentials across platforms was surprisingly inconsistent:

// AWS: Seamless IAM integration
DynamoDbClient.builder()
    .credentialsProvider(DefaultCredentialsProvider.create()) // Just works

// Azure: Requires manual key management  
new CosmosClientBuilder()
    .endpoint(cosmosHost)
    .key(cosmosAuth) // Must manage this key manually

// GCP: Service account JSON (complex but flexible)
GoogleCredentials.fromStream(credentialsStream)

The Reality: AWS has the most seamless credential management, GCP offers the most security options, and Azure sits uncomfortably in the middle with manual key handling.

Monitoring and Debugging Differences

The debugging experience varied dramatically:

AWS: CloudWatch logs are verbose but scattered across services
Azure: Application Insights is excellent but requires separate configuration and has retention limits on free tier
GCP: Cloud Logging is clean and consolidated but sometimes lacks detail

SKU Upgrade Pressure: The Azure Tax

The most frustrating aspect of Azure was the constant pressure to upgrade SKUs for basic functionality:

Feature	AWS	GCP	Azure Consumption	Azure Premium
Custom Domains	✅ Free	✅ Free	❌ Not Available	💰 $150+/month
HTTPS Redirect	✅ Free	✅ Free	❌ Requires CDN	💰 Built-in
VNet Integration	✅ Free	✅ Free	❌ Not Available	💰 Premium only
Deployment Slots	✅ Free	✅ Free	❌ Not Available	💰 Standard+

Lessons Learned: Multi-Cloud Gotchas

Read the Fine Print: Azure's consumption plan is "serverless" in name only - critical features are locked behind premium SKUs
Test Early: What works in development might hit SKU limitations in production
Budget for Surprises: Azure's "free" tier often requires paid add-ons for basic functionality
AWS/GCP Alignment: These two providers have similar feature parity in their free/pay-as-you-go tiers
Documentation Gaps: Azure docs often don't clearly explain SKU limitations upfront

The Bottom Line

While Azure offers excellent enterprise features and integration with Microsoft ecosystems, their consumption-based pricing model feels more like a trial version than a true serverless offering. For small projects and startups, the SKU-based feature gates can be deal-breakers.

Recommendation: If you're building a proof-of-concept or low-traffic application, start with GCP or AWS. Save Azure for scenarios where you're already committed to Microsoft tooling and have budget for premium SKUs.

What I Learned (and Why You Should Try It!)

This challenge was more than just a coding exercise; it was a deep dive into the nuances of multi-cloud development. I gained invaluable insights into:

The subtle (and not-so-subtle) differences between cloud providers for similar services.
The power of Terraform in managing complex, multi-cloud infrastructure.
The art of designing a truly cloud-agnostic application from a single codebase.
GCP had the simplest deployment model with standard Spring Boot, while Azure required the most cloud-specific code but provided the finest control.

If you're looking to level up your cloud game and prove your mettle in the multi-cloud world, I highly recommend taking on the Meta Resume Challenge. It's a fantastic way to solidify your skills and build a portfolio piece that truly stands out.

Feel free to check out my GitHub repository to see the full implementation, and don't hesitate to reach out on LinkedIn if you have any questions or want to collaborate!

Happy building! ☁️

From Dusty Requirements to Live Website: How Claude Code Built My Blog Aggregator in a Single Day

Justin Wheeler — Tue, 08 Jul 2025 18:23:11 +0000

TL;DR

After sitting on a requirements document for over a year, I used Claude Code to build and deploy a complete blog aggregation website in just one day. The site aggregates my posts from multiple platforms under one roof with custom URLs, filtering, and a clean Vue 3 interface. Check it out here or dive into the GitHub repository.

The Problem That Wouldn't Go Away
Enter Claude Code
The Art of Prompt Massaging
What Claude Code Built
Why Netlify Made Perfect Sense
The Claude Code Experience
Lessons Learned
Resources and Downloads

The Problem That Wouldn't Go Away

I've been blogging across multiple platforms for years now, and it's become a bit of a mess:

Bravo LT (my employer): Company blog posts on Wix
Dev.to: Personal posts under my own profile
AWS Community Builders: Technical content under the AWS Builders organization
RedMonk: Participated in their developer certification series

Each platform has its own limitations that drive me crazy. Dev.to appends random characters to URLs making them impossible to guess. I can't customize the slugs for sharing. Some posts are scattered under different organizational spaces. It's chaos.

Back in July 2024, I sat down and wrote a comprehensive requirements document. I knew exactly what I wanted: a single aggregation site that would pull all my content together with custom URLs, filtering, search, and a clean interface. I even specified the tech stack I wanted to learn - Vue 3, TypeScript, Tailwind CSS, and Vite.

Then life happened. Personal obligations, work projects, and the general chaos of existence meant this project kept getting pushed to the back burner. I even reached out to three junior developers about taking it on for a fair rate, but got no takers.

The requirements document just sat there in my Google Drive, collecting digital dust for over a year.

Enter Claude Code

With 2025 winding down and my current project ending, I knew I needed to get serious about client acquisition. Having a professional blog aggregator would be a key part of my online presence. The recent improvements in AI capabilities made me wonder - could I finally tackle this myself?

That's when I discovered Claude Code, Anthropic's agentic command line tool for developers. Unlike traditional AI coding assistants that give you snippets to copy-paste, Claude Code can actually build entire projects from start to finish.

The Art of Prompt Massaging

Here's where things got interesting. Claude Code couldn't directly process my year-old requirements document - it was too verbose and scattered. I needed to translate my original specs into something more digestible.

I went back to the browser-based Claude and had several iterations of conversation to transform my requirements document into a focused prompt specifically designed for Claude Code. This process taught me something crucial about working with AI tools: prompt engineering is an art form.

The original document was eight pages of scattered thoughts, edge cases, and technical musings. The refined prompt was a concise, structured set of instructions that clearly communicated the tech stack, core features, data structure, and design requirements.

This back-and-forth process of refinement reminded me of working with any developer - you need to be clear, specific, and organized in your communication. The difference is that AI tools are incredibly literal, so precision matters even more.

What Claude Code Built

The final result exceeded my expectations. Claude Code delivered:

Core Features:

Single view listing of all blog posts
JSON-driven content management (no code changes needed for new posts)
Custom URL slugs with seamless redirects
Advanced filtering by date range and source platform
Real-time search functionality
Dark/light mode toggle with preference persistence
Fully responsive design

Technical Implementation:

Vue 3 with Composition API
Full TypeScript implementation
Tailwind CSS for styling
Vite for build tooling
ESLint and Prettier configuration
Modern component architecture

The site aggregates content from all my platforms - Bravo LT, Dev.to (both personal and AWS Community Builders), and even my RedMonk video appearance. Each post redirects to the original source while maintaining clean, branded URLs on my domain.

Why Netlify Made Perfect Sense

For hosting, I chose Netlify as a simple, straightforward option. If you're not familiar with Netlify, it's a platform that specializes in static site hosting with some fantastic developer-friendly features:

Key Netlify Benefits:

Instant deployment from Git repositories
Automatic builds triggered by code commits
Built-in CDN for fast global content delivery
Custom domain support with free SSL certificates
Branch previews for testing changes before going live

The deployment process was beautifully simple: connect the GitHub repository, configure the build settings (npm run build with output directory dist), and boom - live website. Any time I push changes to the main branch, Netlify automatically rebuilds and deploys the site.

The Claude Code Experience

Using Claude Code was genuinely impressive. It's currently in research preview and represents a new category of AI tooling - true agentic development assistance.

What makes Claude Code special:

Autonomous execution: It doesn't just suggest code, it writes complete files and manages the entire project structure
Context awareness: It maintains understanding of the project goals throughout the development process
End-to-end delivery: From initial scaffolding to final deployment-ready code

The tool took my refined prompt and built a production-ready application with proper error handling, loading states, and comprehensive TypeScript typing throughout. It created a logical file structure, implemented all the required components, and even included configuration files for the build tools.

About Claude Code:
Claude Code is Anthropic's command line tool that lets developers delegate coding tasks directly from their terminal. It's currently available in research preview and represents a significant step forward in AI-assisted development. You can find more information about Claude Code on Anthropic's blog.

Lessons Learned

This experience taught me several valuable lessons about modern development and AI assistance:

Prompt Engineering is Critical
The difference between my original requirements document and the refined Claude Code prompt was night and day. Taking time to structure your requirements clearly pays massive dividends in output quality.

AI Tools Excel at Implementation
Once I had clear specifications, Claude Code handled all the tedious implementation details flawlessly. It's like having a senior developer who never gets tired and follows instructions precisely.

The Power of Modern Tooling
The combination of Vue 3, TypeScript, Tailwind, and Vite created a development experience that felt both powerful and approachable. Claude Code leveraged these tools effectively to create clean, maintainable code.

Deployment Should Be Simple
Netlify's straightforward deployment process meant I could focus on building rather than wrestling with hosting configuration. Sometimes the simple solution is the right solution.

The most surprising part? This entire project - from dusty requirements to live website - took exactly one day. A year of procrastination solved in eight hours of focused AI-assisted development.

If you're sitting on a project that keeps getting pushed to the back burner, maybe it's time to see what Claude Code can do for you. The technology has advanced to the point where the biggest barrier isn't technical complexity - it's taking the time to clearly define what you want to build.

Resources and Downloads

Want to try this yourself or see exactly how it was done? I'm making the key artifacts available:

📋 Original Requirements Document - The year-old Google Doc that started it all
🤖 Claude Code Prompt - The refined prompt that actually worked!
💻 Live Website - See the final result in action
📦 GitHub Repository - Complete source code and project structure

These documents show the evolution from scattered requirements to focused AI instructions. The contrast between the two approaches really highlights the importance of prompt engineering when working with AI development tools.

Check out the live site and feel free to explore the source code. I'd love to hear your thoughts on the implementation or your own experiences with AI-assisted development.

As always, if you liked this content, maybe you would like to Buy Me a Coffee or connect with me on LinkedIn. Alternatively, you can find all my links on Linktree.

How I Crushed My AWS Certification Renewals Back-to-Back (and Why It Was a Bad Idea)

Justin Wheeler — Thu, 09 May 2024 02:11:47 +0000

I renewed all 12 of my active AWS certifications in 22 days! Most of the exams were back-to-back (based on testing center availability), and I even took two exams in a single day. The entire experience was insanely stressful, yet incredible.

Why?

In January, I was compiling a list of my goals this year, determined to be more accomplished than I was last year. I set some extremely ambitious goals for myself, to say the least. As if they are too ambitious, I guess we will wait and see. Since I had some AWS certifications expiring this year and some next year, I wanted to get them all renewed so I could focus on other priorities next year (Kubernetes, here I come)! The obsessive tendencies in me thought it would be nice if I could align the dates in some logical way rather than the random mess they were previously in. Although I had originally planned on finishing my AWS certifications by the end of Q1, plans changed. Aside from everyday life, there were other complications.

Schedule

4/08 Data Analytics Specialty
4/22 DevOps Engineer Professional
4/23 Solutions Architect Professional
4/24 Advanced Networking Specialty
4/25 Machine Learning Specialty
4/27 Security Specialty
4/29 Database Specialty
4/29 SAP on AWS Specialty

If you didn't already know that professional-level exams automatically renew some lower-level certifications, now you do.

DevOps Engineer Professional renews

Developer Associate
SysOps Administrator Associate
Cloud Practitioner

Solutions Architect Professional renews

Solutions Architect Associate
Cloud Practitioner

Retiring Exams

AWS had announced they were retiring three of their exams, which I already wrote about in Navigating AWS Certifications in 2024.

Data Analytics Specialty (retiring April 8th)
Database Specialty (retiring April 29th)
SAP on AWS Specialty (retiring April 29th)

Obviously, I contemplated skipping these exams; after all, they are retiring. Why didn't I? What's the point? Well, like I already said in this LinkedIn post in regards to the Data Analytics Specialty exam, "I don't agree with Amazon Web Services decision to retire this exam".

Big Data is more important now than ever before. Perhaps the Data Engineer Associate is meant to replace this exam. Although I think we may need a Data Engineer Professional if we expect the same level of depth.

I feel that the Database Specialty is equally valuable. With all of the purpose-built databases that AWS has to offer, it is invaluable to build a strong understanding to ensure the best database for the job can be chosen.

My feelings for the SAP on AWS Specialty are not the same; I'm not terribly sad to see it go, yet I still wanted to renew it. Why?

I had previously planned on taking this exam before I learned about the retirement. If I had skipped it, part of me would have always wondered if I could've actually passed it again.
I wanted to test my SAP knowledge, as I am particularly weak in this domain. Even simple SAP configurations on AWS can easily cost thousands of dollars per month, which makes it impossible to experiment on my own.

How?

I've talked about my study methods before and this time was pretty similar, to be honest. Except this time, I only had to focus on the new stuff since I've already passed these tests before.

These are the websites that I used the most:

Practice Tests

I started with practice tests to gauge my knowledge before hitting the books. This helped me focus on the newer services and concepts I wasn't familiar with.

Did you know that API Gateway can directly call some other AWS services without Lambda? It's called Direct integrations, and it's definitely something I learned through this experience.

The scores varied wildly between A Cloud Guru and CloudAcademy, which was interesting. How can I get a 50% on CloudAcademy and a 90% on A Cloud Guru for the same exam? 🤔

Flash Cards

I used Quizlet to create online flashcards. The AI functionality that has been added to Quizlet recently is really great. I'll highlight two examples.

Magic Notes uses AI to generate flash cards automatically from a large source of text. I used this a couple of times to paste AWS FAQs or documentation.

Q-Chat uses AI to interact with your own flash cards using natural language. With this, I don't have to worry about exactly how my flash cards are typed anymore.

In the middle of this AI storm, it seems like Quizlet is doing AI the right way!

Dedicated Study Time

For a while now, I have always dedicated time every day to studying something. This year, I just focused the allocated time strictly on AWS. Nearing my exams, I would often trade time I would've spent on entertainment like movies or shows for studying instead to ensure I was as prepared as I could be. Do you know how hard it is to study for eight exams at the same time? In my mind, it was similar to "finals week" in college.

Dedicated Testing Time

Typically, when I take a single exam, I will take a half day and be back to work. Although, this was much more taxing, I used a week of PTO so I could focus on my exams exclusively. I prefer testing in person, which resulted in commuting to testing centers that were about 35 miles away. Still, not all of my tests were in person. I did three exams using the online option called OnVUE.

Expenses

The costs can be high for these types of exams. I had access to a bunch of benefits through my company and my engagement in AWS communities.

First, AWS Community Builders and AWS User Group Leaders both provided me with a 100% voucher.

Next, I was able to use multiple 50% vouchers that I had stockpiled from earning all of the certifications previously.

AWS provides benefits to certified individuals.

Finally, Bravo LT reimbursed me for every exam I passed.

Words of Caution 🚧

I will never do this again. If you are thinking of attempting something similar, I hope I can change your mind. Overall, I felt like everything turned out okay, but it could've been far worse.

My mental health suffered from this endeavor in a couple ways. I experienced anxiety, stress, and Imposter Syndrome. I lost enjoyment in my life for a time because I was sacrificing all of my spare time to studying.

My physical health was impacted as well. I found myself skipping meals to finish practice tests or additional lessons. Furthermore, my quality of sleep was affected.

When planning, I want to ask that you don't overwhelm yourself. Give yourself plenty of time to accomplish your goals without rushing.

As always, if you liked this content, maybe you would like to Buy Me a Coffee or connect with me on LinkedIn.

Lessons Learned from Learning Everyday for 4 Years on Pluralsight

Justin Wheeler — Wed, 28 Feb 2024 12:41:16 +0000

Disclaimer

Disclaimer mode activated! While my enthusiasm for Pluralsight (and A Cloud Guru) could fuel a rocket launch, I have zero affiliation with either company (present or past). I'm just a passionate learner, that's all!

Discovery
The Power of Learning Everyday ⚡
Why Pluralsight?
- Learning Streak 🔥
- Certification Prep 📝
- Impressive Catalog 📚
- Official Training
- Skill IQ
Favorite Authors 🧑‍🏫
- A Cloud Guru
- Pluralsight

Discovery 🔭

Personally, I owe the start of my learning journey to Verizon and my amazing manager at the time, Thomas Wise. Verizon had many programs that enabled me to grow. They provided me with an A Cloud Guru subscription when I started pursuing AWS certifications in 2018. After a while, they switched to Pluralsight. I truly don't know why the change was made. Perhaps it was an extended library. 🤷🏻

I chose to maintain my A Cloud Guru subscription on my own and divided my time across the platforms. At the time, I would study cloud technology on A Cloud Guru and literally everything else on Pluralsight. In 2021, I made the tough decision to leave Verizon. Afterwards, I decided to maintain both platforms independently going forward since I knew that I had grown immensely from both platforms.

It's kind of funny that shortly after I found out that Pluralsight acquired A Cloud Guru, which was great news for me since my two favorite learning platforms were merging. The future was indeed bright!

The Power of Learning Everyday ⚡

It has been proven time and time again that it is better to learn a little every day than it is to cram a lot of "learning" into one drawn-out session. The brain can retain information a lot better when it is spread out over time. You may not know just how much learning you can do in just a few minutes a day. I recently read a great blog titled "Learning a Little Leads to Learning a Lot" by Steve Keating that you could quickly read. He states that most people are really busy, but rarely productive.

"One of the most productive things people can do is set aside a few minutes EVERY day to learn something new."

Furthermore, Learnerbly covers many benefits of learning in their blog, "Why is Learning Important? A Deep Dive Into the Benefits of Being a Lifelong Learner" by Melissa Malec. This post breaks benefits into those for our wellbeing and those for our careers.

Some of my favorite quotes from that post are:

Happiness

"Research suggests that people who practice continuous or lifelong learning are happier on average. This may be because lifelong learning helps people to keep developing their passions and interests, which bring us happiness."

Longevity

"Several scientific studies have shown that lifelong learning activities can help people maintain better brain function as they age."

Innovation

"Learning also drives innovation, which describes the new ideas and technological and cultural developments that people come up with to solve problems and improve their societies."

After dedicating time to learning every day for 1,460 days (4 years), I cannot stress enough how beneficial it has been for me.

I have been able to excel in every role that I have held due to rapid upskilling.
I have a different mindset when thinking about technology.
I have found joy in side projects that leverage technology I have never touched before.

Why Pluralsight?

Pluralsight has some of the highest quality training I have ever seen. On top of that, they have a tremendous number of features. Some of which you may not even know about yet.

Learning Streak 🔥

It should be obvious, but there is a built-in learning tracker. Without this, I would not even know that I had studied for 1,460 days. Without this, I don't think I could have done it at all.

Certification Prep 📝

Certification Prep offers one of the best ways to tackle technical certifications.

Hands-on Labs to build real-world skills.
Peer Tracker to compare popularity.
Practice Exams to validate knowledge.
Program Maps to chart certification pathways.

Impressive Catalog 📚

Pluralsight has more than 7,000 courses in its catalog. I can always find at least a little content on even obscure topics like "Quantum Computing."

Official Training

Did you know that Pluralsight has some authors that are official companies?

The content they share here is truly amazing. It is a beautiful thing to see collaboration with third-party training when each of these companies already has their own training platform they would prefer you use instead.

Skill IQ

Skill IQ is an assessment that measures proficiency in a technology skill in 10 to 15 minutes. They have a large range of tests on just about every technology you would like to be tested on, with more coming all the time.

From the Pluralsight Help Center,

"Skill IQ is a continuous score from 0 to 300. This is based on your percentile in that skill area. Pluralsight's exclusive adaptive skill calculations work by measuring your technical abilities relative to the population of users that have taken that assessment. This doesn't measure your broad intelligence. Your percentile tells you how much more you know than others who have the same skill, on a scale from 0 to 100."

After your assessment, Pluralsight can highlight gaps in your knowledge. Better yet, it can link to specific training that you can use to close those gaps right within the Skill IQ assessment page.

Favorite Authors 🧑‍🏫

I know that Pluralsight would be nothing without its amazing authors. I would like to end by recognizing my favorite authors. All of these authors have helped me immensely in different ways. You should check out their content so that they can help you as well!

A Cloud Guru

Faye Ellis for AWS
Mattias Andersson for GCP

Pluralsight

David Tucker for Cloud
Deborah Kurata for Angular
Kate Gregory for C++
Sander Mak for Java

As always, if you liked this content, maybe you would like to Buy Me a Coffee or connect with me on LinkedIn.

Getting Hands-on with Blazor, Next.js and Vercel

Justin Wheeler — Mon, 12 Feb 2024 08:05:05 +0000

TL;DR

I built this website using Blazor and Next.js then deployed both parts to Vercel. If you're interested in the why or the how then keep reading!

Overview
Blazor
- Http.GetFromJsonAsync
- CascadingValue and CascadingParameter
- Oh My Mobile!😱
- Anchor Navigation
Vercel
- Storage
- Security
Next.js
- API
- Deployment
Retrospective

Overview

When planning my 2024 goals, I knew that I wanted to get hands-on with some new technology. Suddenly, I found the following LinkedIn post from Lars Klint.

He mentioned Blazor, which was something I hadn't heard about before. I am traditionally a Java developer, yet I am never afraid to try something new. I quickly prepared myself with a couple amazing courses on Pluralsight.

While training, I was thinking of a practical project that I could use to solidify my knowledge. It was then that I recalled a challenge that Jeremy Morgan had created during his time at Pluralsight that I intended on completing but never started. The first of an incomplete series, "Code Portfolio Challenge" tasked with building a resume website dynamically from a JSON file. Although I missed the deadline back in June 2022 by a tad, I thought this would be the perfect way to flex my Blazor knowledge.

Blazor

I found the coding experience for Blazor to be similar to that of Angular and React. The difference is that my templates, aka razor files, were mixed with C# instead of JavaScript or TypeScript. Shared components could be created and nested in other pages, just like the other frameworks allow.

I decided to run with the default Blazor template that comes from the dotnet new blazorwasm -o TodoList command. The site was aesthetically pleasing from the start. Besides, my goal wasn't to learn CSS; I already knew that.

Http.GetFromJsonAsync

If you're already familiar with C#, then I'm sure you know that you can load a static file using Http.GetFromJsonAsync. That is exactly what I did in order to load the resume.json data that I had created.

// Home.razor
@if (_resume == null)
{
    <h1>Loading...</h1>
}
else
{
    <PageTitle>@Resume.Name</PageTitle>
}

@code {
    private Resume? _resume;

    protected override async Task OnInitializedAsync()
    {
        _resume = await Http.GetFromJsonAsync<Resume>("data/wheeler-resume.json");
    }
}

CascadingValue and CascadingParameter

After hacking away for ten minutes, I realized that this app was going to be terrible if I had to fetch the static resume over and over again on every page I had. CascadingParameter to the rescue!

Cascading values and parameters provide a convenient way to flow data down a component hierarchy from an ancestor component to any number of descendent components.

// MainLayout.razor
<CascadingValue Value="@_resume">
  @Body
</CascadingValue>

// Home.razor
@code {
    [CascadingParameter]
    public MainLayout.Resume Resume { get; set; } = null!;
}

Now any component that needed the resume data could simply wire it up for dependency injection to save the day!

Oh My Mobile! 😱

With the rise of web activity on cell phones, I knew that it wasn't negotiable that even this side project had to work on mobile and look good too. For most of the styles, I could use traditional media queries. Although, in some cases, I wanted to manipulate the HTML itself for mobile. For that to work, I had to fetch the screen size myself.

First, I added the following script to my index.html to create a JavaScript function that I could find with the IJSRuntime. Then I created a service that would allow me to isolate that logic from any specific component, as I knew I would need it in multiple places.

// index.html
<script type="text/javascript">
    window.BrowserServiceGetDimensions = function () {
        return {
            width: window.innerWidth,
            height: window.innerHeight
        };
    };
</script>

// BrowserService.cs
using Microsoft.JSInterop;

public class BrowserService
{
    private readonly IJSRuntime _js;

    public BrowserService(IJSRuntime js)
    {
        _js = js;
    }

    public async Task<BrowserScreenSize> GetScreenSize()
    {
        var dimensions = await GetDimensions();
        return dimensions.Width switch
        {
            >= 1024 => BrowserScreenSize.Desktop,
            >= 768 => BrowserScreenSize.Tablet,
            _ => BrowserScreenSize.Mobile
        };
    }

    private async Task<BrowserDimension> GetDimensions()
    {
        return await _js.InvokeAsync<BrowserDimension>("BrowserServiceGetDimensions");
    }
}

public class BrowserDimension
{
    public int Width { get; set; }
    public int Height { get; set; }
}

public enum BrowserScreenSize
{
    Desktop,
    Mobile,
    Tablet,
}

One usage of this logic was to reduce the number of social icons I displayed on the footer.

// SocialFooter.razor
@code {
    [Parameter]
    public MainLayout.ResumeUrl[] Urls { get; set; } = null!;

    private MainLayout.ResumeUrl[]? _urls;

    protected override async Task OnParametersSetAsync()
    {
        _urls = await GetUrlsForScreen();
    }

    private async Task<MainLayout.ResumeUrl[]> GetUrlsForScreen()
    {
        var screen = await Browser.GetScreenSize();
        return screen switch
        {
            BrowserScreenSize.Tablet => Urls.Take(7).ToArray(),
            BrowserScreenSize.Mobile => Urls.Take(5).ToArray(),
            _ => Urls
        };
    }
}

Anchor Navigation

Frustratingly, anchor navigation didn't work out of the box for Blazor. Luckily, I found Meziantou's blog which had a great workaround that I could use.

private async Task ScrollToFragment()
{
    var uri = new Uri(NavigationManager.Uri, UriKind.Absolute);
    var fragment = uri.Fragment;
    if (fragment.StartsWith('#'))
    {
        // Handle text fragment (https://example.org/#test:~:text=foo)
        // https://github.com/WICG/scroll-to-text-fragment/
        var elementId = fragment[1..];
        var index = elementId.IndexOf(":~:", StringComparison.Ordinal);
        if (index > 0)
        {
            elementId = elementId.Substring(0, index);
        }
        if (!string.IsNullOrEmpty(elementId))
        {
            await JsRuntime.InvokeVoidAsync("NavAnchorScrollToId", elementId);
        }
    }
}

Vercel

I had no prior experience with Vercel before attempting this. I only had the idea because it was one of the few platforms Jeremy mentioned in the challenge posting that I hadn't already experimented with.

I would be lying if I said that I didn't struggle to deploy Blazor to Vercel.

Build Command

dotnet publish --configuration Release --output Publish --self-contained

Output Directory

Publish/wwwroot

Install Command

rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm && yum install dotnet-sdk-7.0 -y

Storage

Maybe that would've been sufficient. Except I accidentally learned about Vercel Storage. Did you know that Vercel has free storage offerings like Redis, Postgres, and Blob? I sure didn't know that. Once I did, I had the crazy idea to enhance this application with a share feature.

I thought it would be interesting for other people to be able to upload their own resume (based on my format) and re-generate the page dynamically. It was easy enough to change the source of the resume in the code. It was much harder to persist that data permanently so that I could recall it with a unique URL.

Because the data uploaded could omit literally any field, I had to cover my bases in the code with lots of null checks. Now the user can choose which fields to retain, and the sections on the page will disappear like magic.

Resume = {}

When importing a JSON, I am saving it in Vercel Blob storage with a unique ID. Then provide a share URL that can be used to reload that same resume. For example, https://cgc-resume-from-json.vercel.app/?id=f87791d3-c359-42e8-8be2-067ce54a2e20.

With this feature, even non-technical people could leverage this site for their own virtual resume without writing any code!

JSON is not code. 😶

Security

Uploading to the Vercel Blob service required some critical thinking. Originally, I didn't want to build a backend for this project. I was pretty fixed on the frontend only.

Unfortunately, it had to be done. You may not know this, but there is absolutely no secure way to protect sensitive keys like the BLOB_READ_WRITE_TOKEN, in a client side app. A sophisticated hacker can find that data.

Next.js

Did you know that Vercel created Next.js? Well, I didn't. That is, until I tried to navigate the Vercel documentation. I have never felt pressured to use a specific technology like the way Vercel pressured me to use Next.js. All of their documentation pointed towards it. Trying to use any other technology seemed like I was on my own.

It was at this pivotal point that I had a decision to make.

Do I jump into Next.js, a framework I've never used, for the ease of documentation and integration?
Do I struggle through the documentation and implementation with a backend framework or language that I already know?

Since I would be struggling in either scenario, I chose to dive into Next.js. I've heard the splash it's made in the community and thought it would be a great learning opportunity.

One more quick course on Pluralsight to ramp up.

Next.js 12: The Big Picture by Cory House

API

I got started with npx create-next-app@latest to scaffold the project. Then I deleted all the files that I didn't need and created a pages/api directory to hold the API code.

Any file inside the folder pages/api is mapped to /api/* and will be treated as an API endpoint instead of a page. They are server-side only bundles and won't increase your client-side bundle size. Docs

For this simple app, I only required a single TypeScript file, blob.ts, with two methods to GET and PUT.

The putBlob function accepts the resume data as the request body in JSON format and uploads the file to Vercel Blob storage using the SDK.

import { put, PutCommandOptions } from '@vercel/blob';
import type { NextApiRequest, NextApiResponse } from 'next';

async function putBlob(
  req: NextApiRequest,
  res: NextApiResponse<BlobResponse>
): Promise<void> {
  if (!req.body) {
    sendError(res, 400);
    return;
  }
  const id = crypto.randomUUID();
  const options: PutCommandOptions = {
    access: 'public',
    addRandomSuffix: false,
    contentType: 'application/json',
  };
  try {
    const result = await put(`${id}.json`, JSON.stringify(req.body), options);
    const { downloadUrl, pathname, url } = result;
    res.status(200).json({ id, downloadUrl, pathname, url });
  } catch (error) {
    console.log(error);
    sendError(res, 500);
  }
}

The getBlob function accepts the unique id as a query parameter and uses that to pull a single blob from the list method.

import { list } from '@vercel/blob';
import type { NextApiRequest, NextApiResponse } from 'next';

async function getBlob(
  req: NextApiRequest,
  res: NextApiResponse<BlobResponse>
): Promise<void> {
  const id = req.query?.id as string;
  if (!id) {
    sendError(res, 400);
    return;
  }
  const result = await list({
    limit: 1,
    prefix: `${id}.json`,
  });

  if (!result?.blobs?.length) {
    sendError(res, 404);
    return;
  }
  const { downloadUrl, pathname, url } = result.blobs[0];
  res.status(200).send({ id, downloadUrl, pathname, url });
}

Deployment

With the end in sight, one last battle. I created a monorepo to improve organization. I didn't want to clutter my GitHub with several disjointed repositories for the same small project.

I couldn't see any clear way to manipulate the "Build & Development Settings" on a per-directory basis. I did see that they had "Root Directory" support at the project level, though. I created another Vercel project for the same GitHub repository. Then I adjusted the "Root Directory" for both projects.

At least since I opted to use Next.js, the presets worked to get the app up.

Retrospective

Looking back, I actually learned a lot. Now I've used Blazor, Next.js, and Vercel. Before I started this journey, I hadn't touched any of them before.

With that said, I don't think that I would go this route again. I was able to stitch these components together like a baby Frankenstein monster, but I don't necessarily recommend it.

To save yourself the headaches I suffered,

Deploy Blazor to Azure
If you want to use Vercel, then use Next.js

I would encourage you to check out the website for yourself. Maybe share it with your friends and colleagues. I would love any brutally honest feedback. https://cgc-resume-from-json.vercel.app/

As always if you liked this content, maybe you would like to Buy Me a Coffee or connect with me on LinkedIn.

Navigating AWS Certifications in 2024

Justin Wheeler — Tue, 30 Jan 2024 16:41:16 +0000

If you are an AWS certificate aficionado like myself then you may already know where this is going. If you're normal then don't scroll away just yet. You may still find value here!

Brief History

The AWS certification landscape has always, to me, been very simple to navigate. There certifications are divided into 4 levels.

Foundational: Building the Bedrock
- Laying the groundwork with essential, non-technical knowledge.
Associate: Bridging the Gap
- Mastering intermediate-level, broad knowledge to bridge foundational and advanced concepts.
Professional: Elevating Expertise
- Scaling heights with advanced-level, broad knowledge, demonstrating mastery in complex AWS scenarios.
Specialty: Fine-Tuning Focus
- Sharpening expertise with advanced-level, specialized knowledge in specific AWS domains.

These Associate and Professional certifications are role-based and are related. Elaborating the Solutions Architect Professional (SA Pro) exam is similar to to the Solutions Architect Associate (SAA), yet elevated in every way. The SA Pro exam is much broader (the number of unique services/features covered) and much deeper (the level of detail required for specific services/features). This relation and progression is natural; expected.

Unlike the role-based paths, the Specialty certifications are built around a strategic area. These are often sought after by experts in the fields they target. That networking wiz you work with may be studying for the Advanced Networking Specialty exam at this very moment. That makes sense, as Enterprise companies may expect that their domain leaders be accredited by AWS as "experts" in those fields they work in. Still I find candidates struggling to comprehend how difficult these exams may be.

If your only goal is to acquire a specialized certification you may not see the need in sitting the Foundational or Associate level exams beforehand. I would implore you to consider a learning path that uses these easier exams as a stepping stone that will solidify core AWS knowledge that could appear on any exam. A few of these critical services are EC2, IAM, S3, and VPC.

Recent Changes

Before you finalize your 2024 goals you may want to consider the recent changes that AWS has been making to their certification program.

In November 2023, AWS announced the new Data Engineer Associate certification. At the same time they marked the Data Analytics Specialty for retirement. These two exams had a similar exam scope so the common perception was that the Data Engineer Associate is a scaled back version of the Specialty exam. After all the Data Analytics Specialty earned a reputation for being difficult.

CBT Nuggets said, "an advanced, challenging certification exam and requires extensive knowledge of data analytics technologies and solutions".
Constantin Lungu "found it legitimately hard".
and many more similar stories.

Given the feedback this change is welcoming, in my opinion. Although, I wish the changes would've stopped there.

Today, AWS announced two more certifications are retiring! 😲

Database Specialty
SAP on AWS Specialty

The Golden Jacket Club

If you didn't know there is a large number of people that have earned all of the AWS certifications, like myself. Many of these people have been given a golden jacket that they boast about on LinkedIn.

Personally I can't help, but feel distraught about these recent announcements. For many others who trained diligently in this epic quest I would bet the feeling may be mutual. It's unclear if these changes indicate that we can expect new exams soon like we saw with the Data Engineer Associate. Alternatively, it could mean that the gaps in the AWS certification curriculum will surely grow. I can reference that there was already a sizable gap in AWS IoT services before these changes.

Part of me is afraid that if a slew of more exams are dropped it will feel like starting over just to get back to where I am now. Maybe I will grow through the journey? Maybe not. Yet if the gaps are left then I fear what that would do. Would Enterprise companies be forced to forego AWS services that don't have accredited training around? Independent companies could validate skills in these areas, but it won't carry the same weight Amazon has. What incentive does a candidate have to study services that they won't be tested on over those they definitely will be?

I wonder if these exams were retired due to lack of participation in these strategic areas, or was it something else? The SAP on AWS Specialty, is shocking to me, since it was announced recently in April 2022.

Looking Ahead

With these recent changes I am almost certain that Amazon is not done yet. I suspect we will see more certification changes announced in the coming months for some of the reasons I covered in this post. It would be nice if the Training and Certification team could tune us into their broader picture. If they did that we could better arrange our AWS training goals for 2024.

Until then you should study cautiously. Keeping in mind that the certification you're targeting may go away before you're ready to sit your exam. That SA Pro at the end of your road map may not be the last stop.

If you liked this content maybe you would like to Buy Me a Coffee or connect with me on LinkedIn.

Parenting vs. Cloud Computing: Overcoming Challenges and Embracing Growth

Justin Wheeler — Mon, 08 Jan 2024 16:32:44 +0000

Background

Over the past seven years, I've been immersed in the tech industry, focusing on cloud computing since 2020. Throughout my journey, I've encountered numerous misconceptions about the field from family, friends, and even colleagues. One of the most common is the belief that cloud computing is too challenging to learn. However, as a father to two beautiful boys, I've come to realize that raising children is far more demanding than mastering cloud computing.

Introduction

If I can do it, so can you! With the increasing shift towards cloud technologies, you might need to adapt to stay relevant in the industry. I've witnessed system administrators managing traditional servers being replaced by new talent due to their reluctance to embrace cloud technologies. As John Maxwell once said, "Change is inevitable. Growth is optional."

Interestingly, many people who are hesitant to learn cloud computing don't question their ability to raise children. In a recent talk titled "False External Perception of the Tech Industry," I explored the accessibility of the tech industry and debunked the myth that it's too difficult to enter.

Comparing Tasks

Changing a Diaper vs. Creating an AWS S3 Bucket

Picture this - it's 3 am, and you're groggily attempting to change a diaper in the dark while your baby wails in protest. Parents know this all too well. In contrast, creating an AWS S3 bucket, a basic cloud storage service, involves a user-friendly interface and just a few clicks. There's no mess, no crying, and no sleep deprivation to worry about.

Gentle Parenting vs. Elasticity in Cloud Computing

The principles of Gentle Parenting, which emphasize empathy, understanding, and respect, share similarities with the concept of elasticity in cloud computing. Both gentle parents and cloud computing systems adapt to changing needs and provide a flexible, nurturing environment. This comparison underscores the importance of adaptability and responsiveness in both parenting and technology.

Handling Tantrums vs. Understanding AWS Lambda

Although seemingly unrelated, handling tantrums and understanding AWS Lambda both require a problem-solving mindset and adaptability. Parents must assess the situation, identify the root cause, and address the issue while comforting their child. Similarly, when working with AWS Lambda, developers need to grasp the underlying triggers, monitor the function's performance, and fine-tune the code and configuration.

Patience and adaptability are vital in both scenarios. Parents should remain calm during tantrums, while developers must be open to exploring different solutions when working with AWS Lambda. Embracing these qualities can lead to success in both parenting and cloud computing.

Conclusion

In conclusion, the experiences of parenting and working in the tech industry, particularly cloud computing, have more in common than one might initially think. Both require adaptability, patience, problem-solving skills, and the ability to learn and grow.

It's important to remember that you have the potential to succeed in the tech industry, just as you do in parenting. Embrace the challenges, invest time in learning, and trust your abilities. As you embark on this journey, you'll find that the tech industry is not as intimidating as it may seem, and the rewards of a successful career in cloud computing can be just as fulfilling as raising well-adjusted children.

Don't let misconceptions or self-doubt hold you back. If you can navigate the complexities and challenges of parenthood, you're more than capable of learning and mastering cloud computing skills. As you continue to grow and develop, you'll be better equipped to face the ever-evolving landscape of the tech industry.

Ultimately, the key to success in both parenting and cloud computing is having the right mindset, persistence, and resilience. By acknowledging that learning and growth are continuous processes, you can foster a positive attitude that will enable you to excel in your chosen career path and create a more fulfilling life for yourself and your family.

Deploying a Mostly Serverless Website on GCP

Justin Wheeler — Tue, 26 Jul 2022 14:45:53 +0000

Introduction

With the technology that we have today there are many options for hosting a website. We are particularly interested in Serverless Computing and opted to run our website in that fashion; well mostly. When we chose Google Cloud Platform, we were unable to find a serverless relational database system. Our Java Spring Boot application was constructed to use a relational database so shifting to another database offering wasn’t something we wanted to do at this time. The architecture that we chose to implement consisted of the following GCP services.

Cloud CDN for distribution and caching
Cloud DNS for DNS registration and routing
Cloud Load Balancing for distribution
Cloud Run for the backend logic
Cloud SQL for persistent storage
Cloud Storage for static website hosting

This Cloud SQL service is the only non-serverless part of the architecture.

Background

Our team is extremely familiar with Amazon Web Services but wanted to explore other clouds to gain that knowledge and provide a personal comparison. We believe that if we simply remain within our comfort zone then we will never truly grow. Additionally, we could be missing out on a better alternative if we lack the courage to explore our options. The bitter truth is that there is no clear-cut cloud provider that is simply better than the rest. You can rank cloud providers on different aspects and shake up the results. The cloud provider that you choose to use should be the one that provides the most value to you for the project that you’re working on.

Infrastructure Deployment

When exploring options on how to deploy the architecture we briefly considered Google Cloud Deployment Manager. Upon further investigation we were led to use Terraform instead. It was evident that Cloud Deployment Manager did not have the necessary support for the resource types that we were trying to create. Many of the supported resource types were still listed in beta.

https://cloud.google.com/deployment-manager/docs/configuration/supported-resource-types

Terraform had complete support for all the necessary resources listed above. We used Terraform Cloud to track the configuration changes and store the state.

Code Deployment

We realized that if we did not automate code deployments our deployed resources would quickly become stale. In the continued spirit to try something new, we decided to use Google Cloud Build for our code automation. With the lack of our code changes this approach turned out to be free for us. We created a build trigger that would watch our GitHub repository and created a cloudbuild.yaml file that would configure the build job. The documentation claimed that just the Dockerfile was necessary, however, in practice we could not get that to work. We were required to create the yaml file for Cloud Build to successfully update the revision on Cloud Run.

options:
  logging: CLOUD_LOGGING_ONLY

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/rest-java:$COMMIT_SHA', '.']
    timeout: 300s

  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/rest-java:$COMMIT_SHA']
    timeout: 300s

  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args: ['run', 'deploy', 'rest-java', '--image', 'gcr.io/$PROJECT_ID/rest-java:$COMMIT_SHA', '--region', 'us-central1']
    timeout: 300s

Serverless Relational Database Offerings

When debating the database solution for our application we were really seeking for a scalable serverless database that wouldn’t bill us for idle time. Options like AWS Athena, AWS Aurora Serverless, and Azure Cosmos DB immediately came to mind. We believed that GCP would have a comparable service, yet we could not find one. Even after consulting the GCP cloud service comparison documentation we were still unable to find any serverless relational database offering. For these reasons we chose the path of least resistance and opted to use a micro instance of Cloud SQL for MySQL.

Operating Performance

With our basic application running on GCP for a couple months we have been pleased with the performance and stability of the architecture. Our Cloud Run scaling settings were intentionally set low to meet application expectations as well as to avoid potential bill shock from an autoscaling fiasco. Like AWS App Runner and AWS Lambda we faced cold start delays when scaling up from zero. We could’ve tried to architect around this with something like an automated trigger or always-running instances. Although, the cold start was not a problem for our use-case. We also felt that provisioning always-running instances defeats the purpose of a serverless service. Can a service be considered “serverless” if it can’t scale down to zero so that you’re not paying for idle compute? We said no.

Operating Costs

We found that GCP costs were comparable to AWS when the services were matched one-to-one. However, because the AWS CDN service CloudFront is a standalone product a simpler, cheaper, alternative architecture is possible on AWS. The GCP CDN service Cloud CDN requires usage in parallel with their Cloud Load Balancer service, which has a minimum operating cost of ~$18/month, even with no traffic. Finally, our Cloud SQL instance bills hourly as well costing us about ~$9/month. This combined ~$27 doesn’t seem like a lot, yet is drastic when comparing low traffic serverless applications that would cost pennies to host on another cloud provider.

Conclusion

In the end we’re glad that we explored this avenue. Our in-depth analysis for this project confirmed that GCP is not the ideal hosting solution for us. The cons for this low traffic serverless application outweigh the pros. We could build a simpler application on AWS with the following changes that would improve the scalability and reduce the cost. Using CloudFront as the CDN removes the need to use the expensive Load Balancing service. Using Aurora Serverless provides us a relational database that can scale to zero so that we’re not paying for idle time. It’s true that Aurora Serverless may face slower query response times when scaling, still we believe it’s worth the cost savings. Lastly, Aurora Serverless would provide the ability to scale past the performance we could have achieved with our single Cloud SQL instance and provided high availability so that we would not be worried about a single point of failure on the database. Perhaps we’ll explore GCP again in the future for another use-case.

If you liked this content maybe you would like to Buy Me a Coffee or connect with me on LinkedIn.

Lightsail - AWS Easy Mode

Justin Wheeler — Mon, 25 Apr 2022 17:06:36 +0000

Overview

Ellis Parry-Nweye and Justin Wheeler have analyzed the AWS product Lightsail and provided their analysis here. The analysis was done by attempting to host a simple Java Spring Boot application on Lightsail Instances. These instances were fronted by a Lightsail Load Balancer. We leveraged Lightsail Object Storage to stage the jar file that we would deploy.
The described architecture could be created using standard AWS services like EC2 for the instances, ELB for the Load Balancing, and S3 for the Object Storage. However, Lightsail aims to provide a single interface to provide the same functionality more simply.

Lightsail even includes simpler variants of other AWS services not analyzed in the current project to keep the original analysis lightweight.

CDN distributions; like CloudFront.
Containers; like ECS.
Databases; like RDS.

Result

The conclusions that were drawn from the project were as follows:

Lightsail can be summarized as "AWS Easy Mode ." The service offers everything that many customers will need and is significantly less daunting than using the other AWS services directly. Straightforward monthly pricing simplifies cloud spending similarly to DigitalOcean. Standard AWS pricing can be incredibly complex.
Lightsail services can be limited and will certainly not be bleeding edge. The configuration options are less than those offered by the aligned AWS services. For instance, using the Lightsail Load Balancer is undoubtedly easier than using the AWS Elastic Load Balancing service. The configuration options provided there are severely restricted. It's not even noticeable which flavor of Load Balancer is used behind the scenes for the Lightsail variant. When the ELB service allows the user to choose the type used first, Application, Gateway, or Network. Then the configuration options explode further to provide complete control.

Facts

Instances

The process to create an instance was plain and simple. The configuration options seemed lacking compared to the overwhelming number of those given within the EC2 console. There is even an option to create multiple instances in a single shot by modifying the quantity input box. Surprisingly the console requires an Availability Zone selection meaning that the bulk creation can only create multiple instances within a single AZ. That logic goes against AWS best practices and will hurt the architecture's high availability/fault tolerance.

One nice benefit of Lightsail instances is that they offer pre-configured click-to-launch applications and stacks that can drastically benefit teams using those services. Some of the popular offerings include WordPress and a LAMP stack. This feature was not explored during the project, perhaps only because a Java solution was not available. Albeit Java is not hard to configure either. The Amazon Linux OS option was selected, and amazon-linux-extras was used to install the required software.

Every Lightsail instance comes with a built-in firewall relatable to a security group in EC2. HTTP and SSH are permitted by default, which doesn't feel very secure. Since this project did not require HTTPS, these default rules were suitable. Along with the firewall, a public IP and private IP can be found on the networking tab of the console. Interestingly a VPC did not have to be created. The assumption is that Lightsail is leveraging VPCs within an AWS-owned account.

Moving on, Lightsail makes creating snapshots easy. These snapshots are a helpful backup tool but are required to resize the instance as well. An insufficient instance was launched for the first attempt that had to be resized to cope with the Java Spring Boot application's requirements. That discovery only occurred after the instance was bootstrapped. Unlike EC2, you will need to snapshot the instance and then launch a brand-new instance from that snapshot if you would like to scale up. Other helpful options were noted, such as the ability to copy to another region or even export the snapshot to EC2.

Some final notes of importance are:

Instance history is tracked, which can be incredibly useful in debugging endeavors and auditing purposes.
Instance metrics are tracked, which can aid in debugging tasks.
It's easy to connect to the instance from the console.
IPv6 networking is also supported.

Load Balancer

For an instance, the Load Balancer was easy to create. Unlike the Elastic Load Balancing service, the Lightsail Load Balancer does not require Target Groups to be made, even if they may be used behind the scenes. The LB provides a DNS name that can be used out of the box. HTTP is enabled by default with the option to allow HTTPS if you conduct a couple of extra steps. That wasn't done since HTTP was sufficient for the use case.

Unfortunately, it was impossible to disable HTTP, and there was no option to redirect HTTP to HTTPS like many services offer. This functionality is available for CloudFront and the ELB service, so, oddly, it was not included here. Further analysis uncovered additional features like session persistence that could be enabled with a simple checkbox. Overall, the Lightsail Load Balancer provided the required functionality with ease and without the bells and whistles that could overwhelm.

Object Storage

Object storage was not used that much during the experiment. It was primarily used to stage the jar file required to run the Java Spring Boot application. It's no surprise that creating a bucket was easy. The domain name is provided when the storage is made s3. This means that S3 is used to support Lightsail Object Storage.

Although, there were crucial differences. Upon creation, a user must choose a bundle that matches the storage and transfer they expect. This is probably to simplify the billing, yet it could mean that Lightsail Object Storage could be more expensive than S3 if you over-provision. Alternatively, if you under-provision, then overage fees per GB apply.

Finally, a good number of features exist for the service, like permission management, metrics, versioning, and logging. These are a subset of what is offered by S3 and are likely very similar. Except most of these were not explored too much during the exercise. Permissions default to least privilege, again like S3. The instances that needed access to the files had to be granted access deliberately. The S3 CLI worked against the bucket when connecting from a Lightsail instance but connecting from outside Lightsail did not work. An invisible barrier separates the Lightsail Object Storage buckets from the S3 buck. There was the discovery of a migration path to S3 if the Lightsail feature set was outgrown.

Conclusion

In conclusion, Lightsail is an excellent service for the right people. It can be thought of as "AWS Easy Mode" as the features and configuration options will surely not overwhelm. The centralized console is polished without the pesky need to remember a hundred acronyms. The pricing is clear, which makes budgeting and planning a breeze. Lightsail offers migration paths that can be followed if the customer ever requires something more without starting over.

To elaborate on “the right people” since it may be broad. The people that would benefit the most from Lightsail would be:

Developers for prototyping work.
New AWS users.
Small scale companies.

Fully AWS Certified - The 5 Most Common Questions I Received

Justin Wheeler — Thu, 17 Mar 2022 16:27:27 +0000

The 5 Most Common Questions I Received

What is the point of pursing every AWS certification?
What training material did I use?
How would you rank the AWS certifications by difficulty?
Which certification path is right for me?
How do I enter the cloud computing industry?

Introduction

After four gruelling years of studying, along with balancing my other responsibilities, I was able to achieve all of the available AWS certifications. Here is my Credly if you would like some proof. When I shared this accomplishment on LinkedIn I received a lot of visibility!

As you can imagine, this attention brought a ton of congratulations and numerous questions. Often these questions were very similar, which gave me the idea to write this post. In doing so I aim to: 1.) Save myself from repeating further; 2.) Provide helpful answers to a greater audience than my LinkedIn inbox. Without further delay the five most common questions I received are after earning all of the AWS certifications are...

1. What is the point of pursing every AWS certification?

I would firstly say that there is no career where it makes sense to obtain every single AWS certification. This is because AWS certifications are created for specific roles. For example, a Cloud Architect should not concern themselves with the Machine Learning Specialty certification (unless they're going to be architecting an ML solution).

Complete A Cloud Guru Certification Guide

With that said, I had created a personal goal for myself to achieve all of the certifications. That's because I actually found joy in learning about each and every piece of AWS. These certification exams made me confident that I was retaining the information that I was learning through my studying. They also provided some information on the "unknown unknowns" so that I could close those gaps that I might not have realized I had.

2. What training material did I use?

I mentioned the training providers that I used in my LinkedIn post as a way of giving credit, but I will go more in depth here so that you can understand how I actually used each provider.

Learning Content
I have used the following providers and believe that A Cloud Guru has the best content.

Pluralsight acquired A Cloud Guru in 2021.

A Cloud Guru's content is enough to pass any AWS certification exam. Their platform has some really nice features like hands-on labs and an exam simulator that does a really good job of simulating a real AWS exam for practice.

AWS Documentation
AWS has amazing documentation that provides great technical details. It is often critical when working in the real world or performing a hands-on lab. Although, you can easily get lost in technical details that will not help you pass an exam. For this reason I typically refer to the documentation only if A Cloud Guru suggests that a particular section is important.

AWS Whitepapers
AWS whitepapers are informational documents that describe best practices in relation to AWS services around a specific topic. Some of these papers can provide answers to the questions found on AWS exams. However, there are too many whitepapers to read them all. Again, A Cloud Guru comes to the rescue by highlighting any whitepapers that should be read for a given exam within their courses.

Practice Tests
I have used the following providers and found that Whizlabs has the best practice tests.

Whizlabs offers multiple unique tests so that you can be guaranteed to see various questions from all of the exam domains to highlight any weak spots in your knowledge.

This varies from A Cloud Guru and Cloud Academy as they only offer a single test that is generated from a question base that is larger than the number of the questions on the exam. Meaning if you take their exam multiple times you will likely see different questions, however, this can't be guaranteed, and you will definitely see repeat questions if you take the test enough times.

Unfortunately the AWS official practice tests are the worst for studying since they don't provide information on questions that are wrong or explanations.

Flashcards
I have only used Quizlet for online flashcards. Whenever I review practice tests I will look at all questions for services or concepts that I was unsure about; even if I got the question correct. Then I create flashcards to solidify that knowledge.

3. How would you rank the AWS certifications by difficulty?

ℹ️ I mentioned this earlier, yet I will reiterate it again. AWS certifications are often associated with a specific role.

That would mean that if you are proficient in that role you will most likely have a much easier time passing that exam than if you are brand new to it. If you're working as a Cloud Architect, than the architecture exams should be easier for you than a Developer taking the same exam. For this reason, these difficulty rankings are based on my personal experience. If you have a different background your opinion may vary and that's expected since you may have domain knowledge that I don't (or did not before studying for the exam).

Here is my ranking from easiest to hardest:

Cloud Practitioner
Developer Associate
Solutions Architect Associate
SysOps Administrator Associate
Security Specialty
SAP on AWS Specialty
Database Specialty
DevOps Engineer Professional
Data Analytics Specialty
Solutions Architect Professional
Advanced Networking Specialty
Machine Learning Specialty

Before I started studying for the Advanced Networking and Machine Learning certifications, I had very little knowledge in these areas. I had to do a lot of studying on the domain before I even looked at any AWS aspects of these so they were extremely difficult for me. Most of the content was brand new to me. If you have prior experience with networking or machine learning concepts you will likely have an easier time tackling these exams than I did.

4. Which certification path is right for me?

ℹ️ I recommend that everyone should start with the Cloud Practitioner certification.

I know a popular opinion in the industry is that this foundational certification is a waste of time, but I see value in it.

Provides foundational experience about cloud computing and AWS
Provides experience on the AWS exam format
Easiest and cheapest AWS exam offered
If you pass, you will receive a 50% off voucher for your next exam

The next certification exam after Cloud Practitioner will vary depending on your career goals.

You want to be an Executive

🛑 Stop! Cloud Practitioner is really all you need.

You want to be an Architect

Cloud Practitioner
Solutions Architect Associate
Security Specialty
Solutions Architect Professional

You want to be a Developer

Cloud Practitioner
Developer Associate
SysOps Administrator Associate
DevOps Engineer Professional

You want to be a Data Analyst

Cloud Practitioner
Solutions Architect Associate
Data Analytics Specialty

You want to be a Machine Learning Engineer

Cloud Practitioner
Solutions Architect Associate
Machine Learning Specialty

These are my opinions based on my experiences.

5. How do I enter the cloud computing industry?

I always say that you can enter the industry by acquiring four things.

a) Certification(s)

The cloud computing industry is composed of multiple roles. It would be better if you decided, which role you would like to target and know that some roles are more difficult to enter than others.

For instance, it may be easier to enter a company as a Cloud Developer that transitions into a Cloud Architect than it may be to enter that same company as a Cloud Architect. Typically Cloud Architects must make really important decisions that can be extremely impactful to companies. For these reasons the barrier to enter is a lot higher.

If you would like some help deciding which role is right for you then I would recommend checking out the So You Want To Be A series from A Cloud Guru.

Certifications can be great tools to help make you stand up, but it won't be enough on it's own. It's also crucial that you actually understand the content that the certification is testing or you won't get far at all. Using exam dumps (cheating) will only cheat yourself.

b) Hands-on Experience

This might be the most important. You need to actually know how to use these things you're learning so much about. If you are studying S3 then you should use S3. Create an AWS account and use it often. Use the console, the CLI, the SDK, etc. Explore the various services, features, and troubleshoot bugs when you run into them (you will run into them). This is truly the only way you will actually learn.

ℹ️ I recommend that if you're worried about using your own AWS account, you consider using a lab or playground environment that is managed by somebody else.

A Cloud Guru Labs

Cloud Academy Labs

Qwiklabs

c) Proof of Experience

Saying you can do something and proving it are very different things. Often times you will need to build a portfolio or repository that you can use to showcase your work. Most companies will not give you a technical interview where you need to login to some AWS environment and complete some task like they might do for a programming assessment. Companies will want you to provide some examples of cloud projects that you've created.

This proof can literally be a large number of things.

Write a CloudFormation template that builds AWS infrastructure
Write a shell script that uses the AWS CLI
Write a python program that reads from a DynamoDB
Write a blog about a new AWS service that you're using

If you are having a hard time thinking of some project to build you should check out the #CloudGuruChallenge from A Cloud Guru. These are realistic problems that don't provide a solution. With these challenges you will get to architect and build the solution yourself.

d) Connections

Social media like LinkedIn can be an incredible tool to help you enter the industry. If you follow the other steps and are actively interacting with the community through comments, posts, blogs, etc. then you will likely draw recruiters to you. When the recruiter reaches out to you, it places you in a much better position than as if you were to apply for the same job from their careers webpage.

You should also be able to breeze through the interview process since you will have the certifications that highlight your experience coupled with the hands-on experience to back that up. You can supply your past projects as proof of experience to the recruiters to stand out even further.

Conclusion

I hope these answers will help you in some way. I would love to hear from you and what other questions you may have for me. Good luck on your cloud journey!

If you liked this content maybe you would like to Buy Me a Coffee or connect with me on LinkedIn.

Forem: Justin Wheeler

Part 2: From $68/month to $5/month - The "Lite" Deployment Strategy

TL;DR

The Problem: When Reality Hits Your Wallet

The Solution: GitHub Pages "Lite" Mode

The Architecture Decision

Why Cost-Conscious Matters

The GitHub Actions Workflow

The Demo-Ready Strategy

What You Lose (and What You Don't)

Production-Grade Practices (The Real Portfolio Value)

1. Feature Flags & Configuration Management

2. Blue/Green Deployment

3. Cost Optimization

4. Infrastructure as Code

5. Graceful Degradation

The Numbers

Was It Worth It?

The Challenge: Your Turn

Connect & Build

Better Late Than Never: Tackling the 2022 Cloud Portfolio Challenge in 2025 (With a Modern Twist)

The Original Challenge (And How I Completely Reimagined It)

Why Digital Ocean? (A Love Letter to Simplicity)

1. Managed Databases (Valkey)

2. Spaces + CDN

3. DO Metrics Agent

4. Credits and Support

5. Domain Management with Namecheap + DO Nameservers

Why Random Prompts? (Safety First)

1. Async Generation Architecture

2. User Input Requires Special Care

3. Prompt Injection Is Real

The Tech Stack That Made This Possible

Backend: Go + Gin Framework

Frontend: Next.js 14

Infrastructure as Code: Pulumi (with Go)

Google Agent Development Kit (ADK)

Hot Storage vs. Cold Storage: Why Valkey Is Optional

Cold Storage: DO Spaces (Source of Truth)

Hot Storage: Valkey (Performance Cache)

The recreate_valkey Flag

Why This Matters

The Build Process: Research First, Deploy Last

Phase 1: Research (research/ directory)

Phase 2: Backend (backend/)

Phase 3: Frontend (frontend/)

Phase 4: Infrastructure (hosting/)

GitHub Actions: The Full Deployment Pipeline

1. Deploy Workflow

2. Teardown Workflow

3. Refresh Workflow

What I Learned (And What Surprised Me)

1. Simplicity Has Value

2. IaC Language Matters

3. AI Agents Are Production-Ready

4. UserData Is Underrated

5. Research Time Is Never Wasted

The Challenge Requirement Checklist ✅

Final Thoughts: Better Late Than Never

What's Next? Stay Tuned for Part 2 📅

Want to Build This Yourself?

Conquering the Multi-Cloud Resume Challenge: My Journey to a Serverless Showcase

Table of Contents

The Challenge: Beyond a Single Cloud

My Multicloud Resume: A Deep Dive

The Architecture: Think Globally, Deploy Remotely

Cloud Provider Implementation: A Complexity Comparison

The Stack: Tried, Tested, and True

State Management with NgRx

Technical Deep Dive: Cloud-Agnostic Business Logic

Database Connector Complexity Analysis

Multi-Cloud Environment Configuration

CI/CD: The Automated Dream

Features that Impress

Performance/Cost Analysis: The Real-World Impact

Cold Start Performance Analysis

Deployment Speed Comparison

Cost Analysis: Monthly Operating Expenses

AWS Infrastructure Costs:

Azure Infrastructure Costs:

The `recreate_valkey` Flag

Phase 1: Research (`research/` directory)

Phase 2: Backend (`backend/`)

Phase 3: Frontend (`frontend/`)

Phase 4: Infrastructure (`hosting/`)