I went through a serverless phase a while back. You know how it is — you read a few blog posts, watch a conference talk, and suddenly you want to put everything in Lambda functions. I'm here to tell you that's a bad idea, but also that serverless is genuinely useful when you use it for the right things.

What serverless actually means

First, the obvious: serverless doesn't mean there are no servers. It means you don't have to think about them. The cloud provider (AWS, Azure, whoever) handles the infrastructure and you just write functions that run when something triggers them. HTTP request comes in? Function runs. File uploaded to S3? Function runs. Timer goes off? Function runs.

It's a nice idea. The reality is a bit more complicated.

AWS Lambda: what I use most

At work we use AWS, so Lambda is what I know best. Setting up a Lambda function is straightforward — you write your function, set a trigger, and you're done. The nice part is that you only pay for the time your function actually runs, which is great for things that don't get called very often.

Here's the thing though: the cold start problem is real. If your function hasn't been called in a while, the first request takes ages because AWS needs to spin up a container. We're talking sometimes 5-10 seconds for a Node.js function. If this is an API endpoint that a user is waiting on, that's completely unacceptable.

I've tried various workarounds — keeping functions warm with scheduled pings, using provisioned concurrency (which costs money, kind of defeating the point), and switching to Python which has slightly faster cold starts. None of them are great solutions.

Where Lambda actually shines for me:

  • Image processing. User uploads a photo, S3 triggers a Lambda function that resizes it, creates thumbnails, and puts them back in S3. This is the textbook use case and it works beautifully.
  • Data transformations. We have a Lambda that processes CSV files dropped into S3, transforms the data, and loads it into a database. Simple, reliable, costs almost nothing.
  • Scheduled tasks. Things that need to run every hour or every day — cleanup jobs, report generation, that kind of thing. No need to keep a server running for that.

Azure Functions: tried it, it's fine

I've used Azure Functions on a couple of projects and honestly it's similar to Lambda in most ways. The triggers are the same concept, the pricing model is comparable, and the cold start problem exists here too.

The main reason I don't use it more is just inertia — our infrastructure is already on AWS and there's no good reason to add another cloud provider to the mix. If you're already on Azure, Functions is perfectly fine. If you're on AWS, stick with Lambda.

One thing I liked about Azure Functions is the local development experience. The Azure Functions Core Tools let you run and debug functions locally more easily than the SAM CLI for Lambda, at least in my experience.

What I've learned

  1. Don't put your entire application in serverless. I tried. The cold starts will kill you, debugging is painful (no local state, limited logging), and you end up with dozens of tiny functions that nobody can keep track of. Use a proper server for your main application.

  2. Keep functions small and focused. Each function should do one thing. If you're writing a function that handles multiple different code paths based on the input, split it up.

  3. Watch your dependencies. The bigger your deployment package, the slower the cold start. I had a Lambda function that pulled in the entire AWS SDK when it only needed S3. Trimmed it down and cold starts improved noticeably.

  4. Logging is not optional. When something goes wrong in a Lambda function, you can't SSH into anything to figure out what happened. CloudWatch Logs is your best friend. Log everything — inputs, outputs, errors, timing. You'll thank yourself later.

  5. Set timeouts properly. The default timeout for Lambda is 3 seconds, which is fine for most things. But if you have a function that does any kind of processing, make sure you set the timeout high enough. I've had functions fail silently because they hit the timeout and I didn't realise.

Serverless is a good tool to have in the toolbox. Just don't treat it like a hammer and see every problem as a nail.