Cloud Frontier

Introduction

Serverless computing has become a buzzword in cloud architecture. But like any tool, it has sweet spots and sharp edges. After building and maintaining several serverless applications, I've learned where it shines and where it creates headaches. This article shares those lessons.

When Serverless Helps

1. Event-Driven Workloads

Serverless excels when your code runs in response to events: file uploads, database changes, HTTP requests. The pay-per-execution model means you don't pay for idle time.

// AWS Lambda handler for image resizing
exports.handler = async (event) => {
  const bucket = event.Records[0].s3.bucket.name;
  const key = event.Records[0].s3.object.key;
  // resize and save
  return { statusCode: 200 };
};

Enter fullscreen mode Exit fullscreen mode

2. Variable or Unpredictable Traffic

If your app has occasional spikes (e.g., a marketing campaign), serverless auto-scales instantly. No need to provision for peak load.

3. Rapid Prototyping and MVPs

You can deploy a fully functional API in minutes without managing servers. This accelerates feedback loops.

4. Microservices and Glue Code

Serverless functions are perfect for small, single-purpose services that connect other services (e.g., processing webhooks, data transformation).

When Serverless Hurts

1. Long-Running Processes

Most providers have a maximum execution timeout (e.g., 15 minutes for AWS Lambda). Batch processing or video transcoding may hit this limit.

# This will timeout if processing takes > 15 minutes
def handler(event, context):
    process_large_file(event['file'])
    return {'done': True}

Enter fullscreen mode Exit fullscreen mode

2. Cold Starts

After a period of inactivity, the first request may have a delay of several seconds. This is detrimental for latency-sensitive applications like synchronous APIs.

3. Stateful Applications

Serverless is stateless by design. If you need persistent connections (e.g., WebSockets) or local state, you'll need additional services like Redis or DynamoDB, adding complexity.

4. High, Steady Load

If your service runs 24/7 with constant traffic, provisioned servers are often cheaper. Serverless per-invocation cost can exceed a fixed monthly server cost.

5. Complex Debugging and Testing

Local emulation (e.g., SAM, serverless-offline) helps but never fully replicates the production environment. Debugging distributed traces across functions can be painful.

Practical Guidance

Use Serverless When:

  • Your workload is event-driven or intermittent
  • You want to minimize operational overhead
  • You need rapid scaling from zero

Avoid Serverless When:

  • You have long-running or stateful processes
  • You need consistent low latency (cold starts hurt)
  • Your traffic is constant and high volume

Conclusion

Serverless is a powerful paradigm, but not a silver bullet. Evaluate your workload's characteristics before adopting it. When used appropriately, it reduces complexity and cost. When misapplied, it creates new problems. Choose wisely.