Chapter 1: Understanding Serverless Architecture

The Cloud Is Not Magic, It's Just Someone Else's Computer

Before we touch a single line of code, we need to reset our mental model.

If you've spent your career writing Ruby on Rails applications, you're used to a certain kind of architecture:

A monolithic app running on Heroku or EC2
A background worker queue (maybe Sidekiq)
A database server (PostgreSQL, of course)
Load balancers, job retries, CRON, and maybe some Redis or caching thrown in

You deploy it all, maybe with Capistrano or Docker, or maybe just from your terminal with a quick Heroku command. And it hums along as long as the servers are happy.

That works fine, until it doesn't.

What Serverless Actually Means

The word serverless is a little misleading. There are still servers. You're just not the one managing them.

Serverless = "event-driven, auto-scaling, pay-per-use infrastructure managed by someone else."

In practice, this means:

You write functions instead of apps.
Those functions run only when triggered, not 24/7.
AWS handles the provisioning, scaling, and teardown automatically.
You only pay for what runs, down to the millisecond.

This model is perfect for bursty workloads, one-off processing, or tasks that don't need a constantly running server.

It's not about replacing your app, it's about augmenting it.

Lambda: The Core of Serverless

At the center of all of this is AWS Lambda.

Lambda lets you:

Upload a function (in Ruby, yes, really).
Define a trigger (like "new file in S3" or "message in SQS" or "manual call from Rails").
Watch it scale and execute independently from your main application.

The best part? No provisioning. No load balancing. No autoscaling groups. No idle EC2 costs. No servers to patch. No Sidekiq processes to monitor.

A Lambda function can spin up in milliseconds, execute, and disappear, without you ever logging into a box.

What Serverless Isn't

There's a lot of hype around serverless, so let's clear the air.

Serverless is not:

A silver bullet for all apps
A replacement for everything
Automatically cheaper (though it usually is for bursty workloads)
Easier to debug (in fact, sometimes it's trickier)

You're trading control for scalability and cost for flexibility. But when used correctly, it's an incredible superpower.

Why Serverless + Ruby Is So Powerful

Here's where things get interesting.

Ruby isn't the first-class citizen in AWS docs like Node or Python, but when you Dockerize your Lambda, the playing field is level.

Using the container runtime:

You can write pure Ruby, with any gems you want.
You control the OS, the Ruby version, the dependencies.
You get around all the weird packaging quirks of native Lambda runtimes.
You can mimic your exact dev environment in production.

Pair this with your existing Rails app, and suddenly you have a hybrid architecture:

Rails handles UI, APIs, DB interactions.
Lambda handles processing files, crunching large data, responding to high-volume event streams, managing bursty workloads, and more.

Each does what it's best at.

When You Should Reach for Lambda

Here are some clear signals that Lambda is a great fit:

✅ Perfect for Lambda

🚫 Not Right for Lambda (Yet)

You have large batch jobs (e.g., CSVs, XML, video processing)
You're dealing with event-driven data (e.g., user uploads, webhooks, API hits)
You need parallelism without spinning up 20 Sidekiq workers
You want isolated fault tolerance for a specific task
You want to scale just one part of your system without deploying your whole app

You need low latency synchronous processing (e.g., <100ms cold starts matter to you)
You have long-running background jobs (>15 minutes)
You need complex local state or access to large local filesystems
You're trying to replicate a whole Rails app inside Lambda (don't do that)

Your Mental Shift as a Ruby Developer

If you're used to monoliths, here's the shift:

Monolith Thinking	Serverless Thinking
Long-lived app process	Short-lived function calls
Always-on workers	Triggered by events
One app = one repo	One function = one concern
Horizontal scaling via EC2	Infinite scaling via Lambda
Cost = uptime	Cost = usage

It's not about rewriting everything. It's about knowing when to offload.

Up Next

In the next chapter, we'll break down the core AWS services that power this architecture.

You'll meet:

Lambda (our hero)
S3, SNS, and SQS (our event delivery crew)
Kinesis and API Gateway (our real-time enablers)
IAM roles and policies (our gatekeepers)

Don't worry, we'll keep it approachable and relevant to Ruby devs. No jargon, just the bits you need.