What Are Serverless and FaaS

What is serverless computing

Serverless computing is a cloud computing model where the cloud provider automatically manages infrastructure. Unlike classic web hosting, scaling, and resource allocation instead of you. Despite the name, servers still exist but you don't think about them or configure them. You write code, deploy it, and the cloud provider takes care of everything else including operating system, runtime environment, scaling, and high availability. You pay only for code execution time, not for time when the server waits for requests.

Serverless is an evolution from physical servers, through virtual machines and containers to a completely abstracted computing model. Each step in this evolution removes one layer of responsibility from the developer and transfers it to the cloud provider. In the serverless model, the developer focuses exclusively on business logic while the cloud provider takes care of everything else, dramatically speeding up development and reducing operational costs for many application types.

Functions as a Service (FaaS)

FaaS is the most recognizable form of serverless computing. In the FaaS model, you write small, standalone functions that execute in response to events. Each function has one clearly defined responsibility, receives input data, executes logic, and returns a result. The cloud provider automatically creates an instance for function execution, executes it, and shuts down the instance when finished. If 1000 simultaneous requests arrive, the provider automatically creates 1000 instances.

Main FaaS providers

• AWS Lambda - first and most mature FaaS service, launched 2014
• Google Cloud Functions - Google's FaaS with good Firebase integration
• Azure Functions - Microsoft's FaaS with excellent .NET support
• Cloudflare Workers - edge computing with global distribution and V8 isolation
• Vercel Functions - optimized for Next.js and frontend frameworks
• Netlify Functions - simple for Jamstack sites

Each provider has specifics regarding supported programming languages, maximum execution time, memory limits, and trigger methods. For a more classic approach, consider cloud hosting service. AWS Lambda supports Node.js, Python, Java, Go, .NET, and Ruby with maximum execution time of 15 minutes and up to 10 GB of memory. Cloudflare Workers use V8 runtime with a 50ms CPU time limit (free plan) but with extremely low latency because they execute on edge locations.

How serverless functions work

When an event triggers a serverless function, the cloud provider goes through several steps. First, it checks if there's a warm instance already initialized and ready for execution. If not, a new instance is created, called a cold start. Cold start includes container startup, runtime loading, your code loading, and initialization logic execution. After that, the handler function executes with data from the event.

Cold start problem

Cold start is the most common source of latency in serverless architecture. For Node.js functions, cold start usually takes 100-500ms, for Python 200-800ms, and for Java it can be 1-5 seconds or more due to JVM initialization. After the first execution, the instance stays warm for some time (usually 5-15 minutes) and subsequent requests execute much faster because they skip initialization.

Strategies for reducing cold start include using lightweight runtimes (Node.js and Python are faster than Java), minimizing deployment package size, using provisioned concurrency (paying for pre-warmed instances), and avoiding heavy initialization in the handler function. AWS Lambda SnapStart for Java and Cloudflare Workers using V8 isolates instead of containers significantly reduce cold start to a level negligible for most applications.

Use cases for serverless

Serverless architecture is ideal for certain workload types while for others it can be expensive or impractical. Understanding the right use case is key for successful application of the serverless model in practice.

Ideal scenarios

• API backends - REST or GraphQL APIs handling HTTP requests
• Event processing - reacting to file upload, database change, queue message
• Scheduled tasks - cron jobs executing periodically
• Image and video processing - resizing, compression, transcoding on demand
• Chatbots and AI inference - processing user messages and AI model calls
• Webhooks - receiving and processing webhook calls from external services
• IoT data processing - processing data from sensors and devices

Less suitable scenarios

Serverless isn't optimal for long-running processes lasting more than 15 minutes, for applications requiring constant low latency (cold start problem), for workloads with constantly high traffic where a dedicated server is cheaper, and for applications requiring local filesystem or long-lasting WebSocket connections. In these cases, containers or traditional servers are a better choice.

Pricing model

One of the biggest advantages of the serverless model is pay-per-use. You don't pay for server idle time but only for time when your code actively executes. AWS Lambda charges per number of requests (EUR 0.17 per million requests) and per execution duration measured in GB-seconds (how much memory the function uses multiplied by execution duration in seconds).

Cost comparison

For a small site or API with 100,000 requests per month where each request takes 200ms with 256MB of memory, the monthly cost on AWS Lambda would be under one euro. The equivalent EC2 server t3.micro costs about EUR 7.30 per month even when it does nothing most of the time. For this workload type, serverless is drastically cheaper.

However, the calculation changes at large scale. For an application with 100 million requests per month, serverless costs can exceed EUR 170 per month while a dedicated server with similar capacity would cost less. The so-called serverless cost cliff arises when workload exceeds a certain threshold where a constantly leased server becomes more cost-effective. For every application, it's important to do a cost analysis for expected workload before choosing a model.

Advantages of serverless architecture

• No infrastructure management - you don't worry about servers, patches, scaling
• Automatic scaling - from zero to million requests without any configuration
• Pay-per-use - you pay only for execution, not for idle time
• Faster development - focus on code instead of infrastructure speeds up delivery
• High availability - cloud provider guarantees availability without your engagement
• Scaling to zero - no costs when there's no traffic

Disadvantages and challenges

Serverless architecture also brings specific challenges. Vendor lock-in is real because each provider has specific APIs, services, and tools that make migration to another provider difficult. Cold start latency can be problematic for applications requiring consistently fast response. Debugging and monitoring are more complex because functions execute in ephemeral environments without access to traditional diagnostic tools.

Local development and testing also represent a challenge because it's hard to replicate the cloud environment locally. Tools like AWS SAM, Serverless Framework, and LocalStack help but can't fully simulate production behavior. Limits on deployment package size, execution time, and memory may require refactoring existing applications. Finally, for teams without cloud services experience, the learning curve can be steep.