If you ever want to test how well you really understand something, try explaining it to your mom. That's exactly what I got to do with serverless.

My mom has been my biggest fan and supporter my entire technical career. A few weeks ago she told me she watches every one of my YouTube videos about serverless and wanted to know — in plain English — what it actually is and why it matters. Just so you know, my mom isn't a developer, but she's pretty tech-savvy. I thought it would be fun to record the whole conversation, and you can watch it here.

I also turned that chat into this blog so anyone who's new to development (or just curious) can follow along easily. So if that's you — welcome! I hope this helps.

Oh, and everyone calls her Mama J… so you can too. Let's dive in!

Serverless starts with servers

Yup, this is the worst-kept secret in all of serverless: it still runs on servers. So, before we talk about serverless, we need to understand what a server actually is and what it does.

The clue is right in the name — a server serves. And what does it serve? Files. That's it. Every website and every web app you've ever used is really just a bunch of different files being delivered to you. Those files are:

• HTML (Hypertext Markup Language) – the content and basic structure of the page
• CSS (Cascading Style Sheets) – the design and layout
• JavaScript – what makes the page interactive
• Media – photos, videos, music, and all the other visual goodies

The client

To talk to a server, Mama J needs a client. A client is anything that can send a request to the server and then show (or use) what the server sends back.

Most of the time, that client is a web browser on her computer, tablet, or phone. But it doesn't have to be! For example, the Amazon shopping app on her phone is also a client. So is the Alexa voice service on her Echo device — when she says "Alexa, order more Diet Dr. Pepper," Alexa acts as the client, talks to Amazon's servers, and gets the job done.

The client's job is always the same: it takes the information the server returns and turns it into something Mama J can see or use.

Here's what happens when Mama J wants to buy her son a birthday gift on Amazon.com:

1. She opens her browser and types Amazon.com.
2. The request gets routed to one of Amazon's many servers.
3. The server processes the request.
4. The server sends back the right HTML, CSS, JavaScript, and media so her browser can build the page.

The processing

That little phrase in step 3 — "the server processes the request" — is where the magic happens. This is where the server applies what we call business logic.

Think of business logic as the "brain" or the special rules that make the website actually useful for Mama J. It's the part that decides what to show her and how to make the experience personal.

For example, when Mama J visits Amazon, the site doesn't just show the same boring homepage to everyone. Thanks to business logic, it remembers she was looking at birthday gifts for her son last week, so it puts a big "Recommended for you" section right at the top with more toys, wrapping paper, and even a suggestion for the perfect card. It also knows she loves Diet Dr. Pepper, so it quietly adds a "Buy it again" button for her favorite 12-pack. None of that happens by accident — the server ran its rules: "If this is Mama J, show her the stuff she actually cares about."

The same thing happens on Facebook. When she logs in, the business logic looks at who she follows, what she's liked before, and even how long she usually spends reading family posts. Then it builds her entire news feed so the first thing she sees is a photo of her grandkids, not some random political rant. It's all custom-made just for her.

How does any of this work? Because she logged in, so the system knows it's Mama J. The server then runs its business logic — basically a set of smart instructions that say, "If this is Mama J, show her her stuff, in the order she'll like best." That's business logic in plain English.

The challenge of running servers

Servers are incredible — they power everything from video games to generative AI. But running them comes with some serious headaches.

Security and maintenance

Servers need constant care. New threats appear every single day. If your server is open to the internet, you have to be an expert in secure networking, operating-system patching, hardware upgrades, monitoring, and a dozen other things. You can't just set it and forget it — it demands 24/7 attention.

Availability and scalability

Websites have to stay up 24 hours a day, 7 days a week. That means you need at least two servers so one can cover for the other if something breaks. In reality, big sites run on thousands of servers spread across different geographic areas. They also use auto-scaling to spin up more servers when traffic spikes and scale back down when it drops.

Paying for idle services

All of that means you're paying for servers to sit there running… even when nobody's using them. Mama J nailed it when she said, "It's like keeping a restaurant fully staffed day and night, whether you have customers or not."

That's what we call idle time — and idle time is expensive.

So Mama J asked the million-dollar question: "Why don't we just call the staff in when the customers actually show up?"

Great question, Mom. That's exactly what serverless does.

The serverless approach

At AWS we've been running Amazon.com at massive global scale for over 30 years, so we know a thing or two about servers. We looked at how companies were struggling with all the work it takes to keep servers running and decided we could make it simpler.

What we set out to build

We wanted to build something that would let developers run their code at any scale without having to manage servers, security patches, scaling, or any of the other stuff that's the same for every company. We call that "undifferentiated heavy lifting."

We wanted developers to focus on their ideas instead of infrastructure. We wanted the system to handle huge traffic spikes automatically, and we wanted them to pay only for the time their code was actually running — basically, wake everything up only when customers show up.

AWS Lambda

AWS Lambda is a service that runs your code without you managing any servers. You write your code, deploy it to Lambda, and it takes care of the infrastructure — servers, networking, security, and scaling.

When a request comes in, here's what happens:

• Lambda spins up a small execution environment to run your code
• Your business logic does its thing
• The response goes back to the user

The first time this happens, Lambda has to set everything up from scratch — that's called a cold start. After that, the environment hangs around for a while, ready for the next request. If another request comes in while it's still warm, it reuses that same environment — a warm start — and it's faster. But if things go quiet for too long, Lambda cleans it up and the next request starts fresh again.

Pricing

The pricing model is pay-per-use. You're charged based on the number of requests and how long each one runs. No requests, no charge.

For example, a website handling 1 million requests a month — each taking half a second with 512 MB of memory — would cost about $4.37 total. A traditional server running 24/7 costs $15–$30 a month, and you'd need at least two for availability, so $30–$60 a month regardless of traffic. With Lambda, a month of zero traffic costs $0.00.

Scalability

Lambda also scales automatically. By default, your AWS account gets 1,000 concurrent Lambda executions per region — that's 1,000 separate copies of your code running at the exact same time, shared across all your Lambda functions in that region. That's a soft limit — if you need more, you can request an increase from AWS. But for most workloads, 1,000 is more than enough.

To put that in perspective — say Mama J's website goes viral and 1,000 people all hit it at the same second. Lambda spins up 1,000 environments, one for each request, handles them all simultaneously, and sends back 1,000 responses. And since each request typically finishes in milliseconds, those 1,000 slots free up almost instantly and are ready for the next wave. In practice, that means Lambda can handle tens of thousands of requests per second without you configuring anything. With a traditional server, you'd be scrambling to spin up more machines before the traffic crushes you.
scale

Right tool for the job

"So, I should just use Lambda for everything?" Mama J asked.

Not quite. Lambda is a great fit for most things — web backends, APIs, data processing, scheduled jobs, chatbots, mobile backends, and event-driven architectures. For the majority of workloads, it's where I'd start. But there are a few situations where it's not the right tool:

• Long-running workloads — A single Lambda invocation has a 15-minute maximum, and that applies to synchronous execution. For workloads that need to run longer — heavy video encoding, large data migrations, overnight batch jobs — you'd traditionally reach for something like Amazon ECS or AWS Batch. However, the new AWS Lambda durable functions feature changes the game by letting you build long-running asynchronous workflows that coordinate across multiple Lambda invocations, well beyond the 15-minute limit. It's a big step forward, but you still need to plan your architecture around it.
• Ultra-low latency at very high throughput — Some workloads need extremely predictable response times at massive scale, like high-frequency trading systems. In those cases, always-on compute can give you tighter control.
• Big legacy monoliths — If you've got a large, tightly coupled application, breaking it into small Lambda functions can be painful. That's more of an architecture challenge than a Lambda limitation, but it's worth knowing.

The thing is, it doesn't have to be all-or-nothing. Most real-world systems use a mix — Lambda where it fits, and other services where they're a better match. But Lambda is still the default starting point for most new projects because it takes so much off your plate.

Wrapping up

Mama J sat back and said, "So let me make sure I've got this. Instead of buying servers, keeping them running, paying for them when nobody's using them, and worrying about security, availability, scalability, and maintenance — you just write your code and Lambda handles the rest?"

Pretty much, Mom. That's serverless in a nutshell.

This is just the beginning, though. Lambda on its own is powerful, but the real fun starts when you connect it to other AWS services and build event-driven applications — things that react automatically when something happens, with no servers to manage anywhere in the stack.

We'll get into all of that in the next post.

Stay tuned!