[2025 Update: Lambda won. Serverless functions are now standard practice, with Cloudflare Workers, Vercel Functions, and others following AWS's model. The deployment experience improved dramatically with infrastructure-as-code tools like the Serverless Framework, SAM, and CDK. But the core insight here—that constraints can improve design—remains relevant.]

I tested AWS Lambda at a hackathon. It changed how I think about microservices architecture.

What Lambda Solves

Before Lambda, deploying backend code meant provisioning servers, managing OS updates and security patches, scaling infrastructure manually, and paying for idle capacity around the clock.

Lambda flips this. You write a function, upload it, and AWS handles everything else. You pay only for execution time, down to 100ms increments.

The promise: Focus on code instead of infrastructure.

The reality in 2016: The deployment experience was primitive.

The Lambda Model

The idea isn't new—Google App Engine did something similar earlier. You send source code to AWS. It prepares it on a server and exposes an index.handler. This handler exposes APIs you call through REST (via API Gateway) or trigger from other AWS services.

A basic Lambda function in 2016:

exports.handler = function(event, context) {
  console.log('Processing event:', event);

  // Your business logic here
  const result = processData(event.data);

  context.succeed(result);
};

The complexity came from the deployment process.

The "Bad" Deployment Experience

The only way to deploy was uploading a ZIP file. Two options:

1. Direct upload: ZIP your code and upload through the AWS Console
2. S3 upload: Push ZIP to S3, then reference it in Lambda

There was no CI/CD integration, no automated testing, and no gradual rollouts — just ZIP and upload.

Coming from systems with git push deployments, this felt like a step backwards.

Why Friction Helped

Here's my contrarian take: the terrible update interface worked in Lambda's favor.

The deployment friction discouraged frequent deploys. I found myself splitting code into small, focused pieces. Once a piece of code reached stability, it didn't need touching anymore. You don't want to redeploy it just because adjacent code changed.

This constraint reinforced the core microservices idea: doing one small thing reliably.

The Mental Shift

Traditional deployment encourages monolithic thinking:

• "I'll add this feature to the existing service"
• "Let me update this while I'm here"

Lambda's friction encourages modular thinking:

• "Does this deserve its own function?"
• "Can I make this completely independent?"
• "What's the smallest unit I can deploy?"

The deployment pain made me think harder about boundaries. Each Lambda function became focused on a single responsibility.

How This Changed My Approach

At the hackathon, I started with one Lambda function doing everything. After the third painful ZIP upload, I split it:

• auth-handler: Validates tokens, nothing else
• data-processor: Transforms input, no side effects
• notification-sender: Sends emails, decoupled from other logic

Each function could be updated independently. Each had a single reason to change. The friction forced better software engineering discipline.

The Broader Lesson

Lambda's clunky deployment wasn't an oversight—it reflected AWS's serverless philosophy. Functions should be small, focused, and stable. If you're deploying constantly, you're probably doing too much in one function.

Modern developer tools have smoothed deployment with Serverless, SAM, and Terraform. These tools improve productivity, but something was lost: the forcing function that made you think about modularity.

Sometimes friction is a feature. The best constraints push you toward better solutions.

Lambda in 2016 vs. Today

The platform has matured since then—containerized functions, streaming responses, better monitoring. The core insight remains: the best tools make you think differently about problems.

Lambda pushed me to think small and modular. That approach turned out to be exactly right.

Fast forward to 2025, and the serverless landscape evolved. Cloudflare Workers offers similar serverless capabilities with edge deployment and simpler configuration than Lambda. The fundamentals from Lambda's early days still apply, but the tooling has gotten much better.