Cloud Frontier

Posted on Sep 1

Serverless: When It Helps and When It Hurts

#serverless #aws #architecture #webdev

The Hype and the Hangover

Serverless is one of those buzzwords that promises to free you from infrastructure. "No servers to manage!" they say. And it's true, but only up to a point. I've built and operated serverless systems that were a joy, and others that were a nightmare. The difference wasn't the technology, it was whether I applied it where it actually fits.

Let's be clear: serverless (FaaS like AWS Lambda, Google Cloud Functions, Azure Functions) is not a silver bullet. It's a tool with a very specific shape. Use it for the right problems and it's fantastic. Use it for the wrong ones and you'll be fighting it every step of the way.

When Serverless Helps

1. Spiky and Unpredictable Traffic

If your workload has sudden bursts, long idle periods, or a pattern that's hard to forecast, serverless shines. You pay per invocation, so idle time costs almost nothing. A cron job that runs once a day? A webhook that gets hit a few times per hour? Perfect.

For example, a small image resize endpoint:

// AWS Lambda with Node.js
exports.handler = async (event) => {
  const { image, size } = JSON.parse(event.body);
  const resized = await resize(image, size);
  return { statusCode: 200, body: JSON.stringify({ url: resized }) };
};

No EC2 instance sitting there 24/7. No autoscaling group to configure. The platform scales to zero when idle and to a thousand concurrent requests when a viral post hits.

2. Event-Driven Processing

Serverless is designed for events. File uploads, database changes, queue messages, IoT telemetry. You write a small function, connect it to an event source, and you're done. The plumbing is handled for you.

For instance, processing a new upload:

# AWS Lambda with Python, triggered by S3
def handler(event, context):
    for record in event['Records']:
        key = record['s3']['object']['key']
        process_file(key)

The function runs exactly when the event happens, no polling, no waiting. That's the sweet spot.

3. Small, Independent Microservices

If you have a service that does one thing, has a small codebase, and doesn't need to maintain long-lived connections, serverless is a great fit. It forces you to keep functions small and focused, which is good discipline.

When Serverless Hurts

1. Long-Running or Stateful Workloads

Lambda has a 15-minute timeout. If you need to process a large file, run a complex computation, or maintain a WebSocket connection, you're going to hit a wall. You end up splitting work into chunks, coordinating state externally, and debugging distributed timeouts. That's pain you didn't need.

2. Low-Latency, High-Frequency Calls

Cold starts are real. If your function is invoked a few times per second and each call needs to be under 50ms, serverless can be a problem. The first call after idle can take a second or more. You can work around it with provisioned concurrency, but that starts eating into the cost savings.

3. Complex Applications with Tight Coupling

If your application is a monolith that shares in-memory state, serverless forces you to break that. You'll need external caches, databases, and message queues for everything. The overhead of managing that may be worse than just running a simple VM.

4. Unexpected Costs at Scale

Serverless pricing looks great at low volume. But when you're processing millions of requests, the per-invocation cost adds up. A long-running function that's called frequently can be more expensive than a dedicated instance. I've seen teams get a surprise bill because a function was written inefficiently (e.g., reading a large file into memory on every call).

Decision Framework

Ask yourself these questions before going serverless:

Is the workload event-driven or request/response? Event-driven fits.
Is the traffic predictable and steady? If yes, a container or VM might be cheaper and simpler.
Do I need sub-second latency consistently? Cold starts might kill you.
Can I break the work into small, stateless units? If not, you'll fight the platform.
What's the total cost at peak? Run the numbers for both options.

Final Thoughts

Serverless is not a religion. It's a tool. I've used it to build a video transcoding pipeline that only runs when someone uploads, saving 90% of the cost of a dedicated worker. I've also seen a team try to run a real-time chat app on Lambda and spend weeks fighting connection limits.

Start small. Prototype a single function. Measure cold starts, latency, and cost. If it feels like you're bending the platform to your will, step back and consider a more traditional approach. The best architecture is the one that solves your problem without making you hate your job.

Remember: "serverless" doesn't mean "no servers." It means "servers you don't have to think about." And sometimes, you absolutely should think about them.

DEV Community