Understanding Serverless Computing and lambda

Serverless

First, let’s understand what serverless actually means.

In the traditional way of building applications, you build your application and host it inside a server. But when doing that, writing the application itself is not the only thing you need to care about. You also need to think about RAM, storage, network bandwidth, operating systems, security patches, scaling, monitoring, load balancing, backups, and many other infrastructure-related things.

So eventually, developers spend a huge amount of time handling infrastructure rather than focusing only on actual business logic and features.

Even after managing all of that properly, there is still another major issue — unpredictable traffic.

Think about a normal news website. Usually it may only receive around 50 concurrent users. That is very manageable. But suddenly one random news article goes viral. Now instead of 50 users, the application starts receiving 1,000 or even 100,000 users at the same time.

Now scalability becomes a real problem.

In traditional systems, servers usually scale vertically. That means you need to add more resources to the servers other wise you need to add more servers and then handle things like load balancing, traffic distribution, failovers, health checks, and synchronization between servers. Even if you decide to buy a very powerful server to avoid those issues, it still creates another problem because most of the time those resources stay unused during low-traffic periods. So now you are basically paying for resources that are sitting idle.

This is exactly the kind of problem serverless computing tries to solve.

With serverless architecture, developers mainly focus on writing code and business logic. Infrastructure management, scaling, availability, server maintenance, and most operational tasks are handled by the cloud provider itself.

Another huge advantage is the pricing model.

Instead of paying for servers running 24/7, you usually pay only for actual usage. So if your application only receives 50 requests, you pay only for those 50 requests. If traffic suddenly spikes to 1000 requests, the platform automatically scales and you pay according to that increased usage. There is no need to maintain expensive always-running infrastructure just in case traffic increases someday.

Of course, if you already know your application will always have some guaranteed traffic, providers like AWS also offer saving plans and reserved pricing models. In those cases, you commit to a baseline amount of usage while anything exceeding that still follows the pay-as-you-go model.

Today, almost every major cloud provider offers serverless platforms.

For example:

• AWS provides Lambda
• Google Cloud provides Cloud Functions
• Microsoft Azure provides Azure Functions

AWS Lambda functions

Among these, AWS Lambda is one of the most widely used serverless services, so let’s understand how it actually works.

At the center of AWS serverless architecture is something called a Lambda function.

A Lambda function is basically a small piece of code that runs only when something triggers it. Unlike traditional servers that continuously stay running waiting for requests, Lambda functions execute only when needed.

These functions can be triggered by many different AWS services. For example, an HTTP request coming through API Gateway can invoke a Lambda function. Uploading a file into an S3 bucket can trigger another Lambda function. Even database updates, scheduled jobs, queue messages, or authentication events can trigger functions automatically.

This event-driven nature is one of the biggest reasons serverless architectures feel very flexible and modular.

Inside every Lambda function there is also something called a function handler. The handler is basically the entry point of the function. Whenever an event comes in, the handler receives that event and starts processing the logic.

For example, if an API request comes in, the handler receives request data and returns a response. If an S3 upload happens, the handler receives metadata about the uploaded file and processes it accordingly.

Behind the scenes, AWS automatically manages something called the execution environment. This environment contains all the resources required to run the function such as allocated memory, temporary storage, runtime initialization, and isolated execution resources.

The interesting thing here is developers usually do not need to manually manage any of these environments. AWS creates, scales, reuses, and destroys them automatically depending on incoming traffic.

The function itself runs inside a runtime environment which depends on the programming language you use. AWS Lambda supports multiple runtimes including Node.js, Python, Java, Go, and .NET.

Now when a Lambda function runs, it usually goes through three main stages.

First comes the initialization phase. During this stage AWS prepares the execution environment, loads dependencies, initializes the runtime, and prepares your code to run.

Then comes the invocation phase which is the actual execution of your business logic. This is where the function processes incoming requests or events.

Finally comes the shutdown or reuse phase. AWS may either terminate the environment completely or keep it alive temporarily so future requests can reuse it faster.

This reuse behavior is actually very important because it directly connects to one of the biggest trade-offs in serverless systems — cold starts.

Limitations

Sometimes when a Lambda function has not been used for some time, AWS removes the execution environment to save resources. So when the next request arrives, AWS has to initialize everything again from scratch. That extra initialization time is called a cold start.

For lightweight applications this delay may not be very noticeable, but for larger applications it can sometimes become an issue.

Still, there are several ways to reduce cold starts. AWS provides Provisioned Concurrency which keeps a predefined number of execution environments warm and ready. Some teams also use scheduled EventBridge triggers to periodically invoke functions and prevent them from becoming inactive.

Even though cold starts are a known limitation, modern serverless platforms have improved massively compared to earlier implementations.

Another important limitation is execution duration.

AWS Lambda functions cannot run forever. Standard Lambda executions currently have a maximum execution time of 15 minutes. For many workloads this is completely fine because serverless is mainly designed for short-lived event-driven processing.Recently AWS also introduced something called durable functions for long-running workflows. Unlike standard Lambda executions which are limited to 15 minutes, durable functions can pause, resume, and maintain state between steps. This makes them useful for workflows that may take hours, days, or even months to complete. Instead of running continuously like a traditional server process, the workflow checkpoints its progress and continues when the next event arrives. It is especially useful for orchestrations, approvals, batch pipelines, and long-running distributed processes.

But sometimes applications need very long-running continues tasks like large video processing pipelines, complex report generation, or huge data transformation jobs. In such situations developers usually break workflows into smaller independent steps and connect them using queues, events, or orchestration services like AWS Step Functions.

This works very well for many distributed systems, but there are still scenarios where continuously running servers may make more sense.

There are also some additional challenges when working with serverless architectures.

One of them is debugging complexity.

In traditional monolithic applications, debugging is relatively straightforward because most things happen inside one application. But in serverless systems, requests may travel through APIs, queues, multiple Lambda functions, databases, and event streams before completing a single workflow.

So tracing issues across the entire system becomes more difficult. Because of this, monitoring tools like CloudWatch, X-Ray, Datadog, and OpenTelemetry become very important in serverless applications.

Another thing to remember is that Lambda functions are stateless by default.

That means functions should not depend on local memory or temporary files for long-term storage because execution environments can disappear at any time. Instead, persistent data is usually stored in services like DynamoDB, S3, Redis, or relational databases.

There is also the issue of vendor lock-in.

Since serverless architectures often depend heavily on cloud-provider-specific services like Lambda, API Gateway, DynamoDB, EventBridge, and Step Functions, migrating to another cloud provider later can become difficult and require significant architectural changes.

So what you think ? any additions!