History of Serverless #

Serverless is often seen as a sudden innovation that arrived with the new generation of cloud. In reality, this paradigm is the result of a long evolution in how humans build, run, and manage computing systems. Understanding its history helps you see why serverless emerged, what problems it actually solves, and where this trend is heading.

This article traces the journey of infrastructure from physical servers on data center racks, through virtualization and cloud, to the eventual birth of Function as a Service. By the end, we’ll have a complete picture of serverless’s place in infrastructure history — not just a list of features, but the context behind them.

Infrastructure Evolution Timeline #

Before diving into details, let’s look at the big picture of this journey. Each phase builds the foundation for the next, and each phase leaves unsolved problems behind.

flowchart TD
    A["1990s: Physical Servers (Bare Metal)<br/>- Developers doubled as Sysadmins<br/>- Static capacity, slow provisioning"] --> B["2000s: Virtualization (VMware)<br/>- One physical hardware shared across VMs<br/>- Started separating OS from hardware"]
    B --> C["2006: AWS EC2 (IaaS)<br/>- On-demand server provisioning via API<br/>- The birth of commercial Cloud Computing"]
    C --> D["2008: Google App Engine (PaaS)<br/>- Deploy app code directly without managing OS<br/>- First runtime abstraction"]
    D --> E["2010s: Microservices Architecture<br/>- Monolith apps split into small units<br/>- The need for more efficient deployment units"]
    E --> F["2014: AWS Lambda (FaaS)<br/>- Request-based event-driven compute<br/>- The birth of the modern Serverless era"]
    F --> G["2015+: Serverless Ecosystem Expands<br/>- Serverless Database, Storage, Messaging, and Auth<br/>- Cloud providers manage the entire infrastructure"]

The timeline looks gradual, but every leap was triggered by the same problem: infrastructure operational burden that was too heavy for developers.

The Early Era: Physical Servers and Manual Management #

In the earliest phase, applications ran directly on physical servers (bare metal). One application — or one system — usually occupied an entire server unit. There was no logical resource sharing, no abstraction.

The main characteristics of this era can be summarized as follows:

Physical Server (Bare Metal):
  ✓ Applications are physically and fully isolated
  ✓ Very stable, predictable performance
  ✗ Capacity must be estimated and ordered far in advance
  ✗ Scaling only possible by adding physical hardware
  ✗ Slow deployments, often accompanied by downtime
  ✗ One server for one primary function — highly inefficient

During this era, developers doubled as sysadmins. Their responsibilities didn’t stop at writing code; they also included:

• Choosing hardware specifications, ordering them, and racking them in the data center.
• Installing the operating system (OS) and dependencies manually.
• Configuring physical networking, firewall rules, and DNS servers.
• Applying operating system security patches periodically.
• Manually monitoring servers 24/7.
• Managing data backups, system restoration, and disaster recovery.

This model has one fundamental problem: infrastructure is static, while application workloads are highly dynamic. If the application suddenly gets 10x more users on launch day, the only solution is to order new servers — a procurement process that takes weeks or even months.

The classic bare metal problem: capacity is provisioned to anticipate the peak load, while average daily usage sits around only 10–20%. The remaining 80% of hardware resources sit idle but still have to be paid for in full. This is what’s called over-provisioning — the biggest financial inefficiency of the physical server era.

Virtualization: The Beginning of Infrastructure Abstraction #

Around the early 2000s, virtualization technology began entering the industry at scale through hypervisors like VMware ESX, Xen, and later KVM in Linux environments. For the first time, a single physical server could be logically divided into many Virtual Machines (VMs) running isolated from one another.

The Impact of Virtualization #

flowchart LR
    A["Physical Server 1"] --> H1{"Hypervisor"}
    A2["Physical Server 2"] --> H1
    H1 --> V1["VM App A"]
    H1 --> V2["VM App B"]
    H1 --> V3["VM App C"]
    H1 --> V4["VM Dev/Test"]

Virtualization brought major changes to hardware efficiency:

The Unsolved Limitation #

Although virtualization successfully solved hardware efficiency, the operational management paradigm barely changed. For developers, a VM is still a server. A VM still has a full operating system that needs manual maintenance: security patching, networking configuration, package manager installation, user management, and system failure handling. The sysadmin burden merely shifted from physical to virtual.

Infrastructure as a Service (IaaS): The Birth of Cloud Computing #

The year 2006 marked the birth of the modern cloud computing era when Amazon Web Services (AWS) launched Elastic Compute Cloud (EC2). AWS rented out VMs (EC2 instances) on demand, instantly provisionable through an API (Application Programming Interface). This paradigm is known as Infrastructure as a Service (IaaS).

IaaS vs. Traditional Data Center #

IaaS Is Not Serverless #

Although it makes things much easier, IaaS is still not serverless. In the IaaS model, the concept of a server remains very visible to developers.

flowchart TD
    A["Developer"] -->|"still manages"| B["OS + Runtime"]
    B --> C["VM / Instance"]
    C --> D["Hypervisor"]
    D --> E["Physical Hardware"]

    style A stroke:#ff5555,stroke-width:2px
    style B stroke:#ff5555,stroke-width:2px

The red color in the diagram above marks the layers that remain the developer’s full responsibility under the IaaS model. The cloud provider handles physical hardware and hypervisors, but developers still have to deal with OS installation, runtime dependencies, auto-scaling management, and security patching. If application traffic suddenly spikes, developers have to design complex auto-scaling group rules themselves so new VMs can spin up in time.

Platform as a Service (PaaS): Higher Abstraction #

Seeing that developers were still burdened by operating system management, Google took an innovative step in 2008 by releasing Google App Engine (GAE), introducing the Platform as a Service (PaaS) concept to the global market.

The PaaS Philosophy #

The PaaS philosophy is based on one core idea: developers don’t need to know or care about the operating system underneath their code.

sequenceDiagram
    participant Dev as Developer
    participant PaaS as Platform
    participant Infra as Infrastructure

    Note over Dev,PaaS: Old Model (IaaS)
    Dev->>Infra: provision server
    Dev->>Infra: install runtime
    Dev->>Infra: deploy code
    Dev->>Infra: configure scaling
    Dev->>Infra: monitor

    Note over Dev,PaaS: New Model (PaaS)
    Dev->>PaaS: push code
    PaaS->>Infra: handle everything
    Infra-->>PaaS: running
    PaaS-->>Dev: deployed ✓

Developers just push their application code to the platform, and the PaaS system handles compilation, runtime provisioning, web server configuration, load balancing, and basic auto-scaling.

Popular PaaS Providers #

• Google App Engine (2008): Pioneered PaaS with early support for Python and Java runtimes.
• Heroku (2009): Very popular among startups because of the easy deployment via git push heroku master.
• Microsoft Azure App Service (2010): Focused on tight integration with the .NET and Windows Server ecosystem.
• AWS Elastic Beanstalk (2011): AWS’s PaaS solution that wraps the underlying IaaS resources for easier management.

PaaS Limitations #

PaaS offers incredible deployment speed, but it has several critical limitations that make it less flexible:

PaaS is great for:
  ✓ Standard monolithic web apps (HTTP request/response)
  ✓ Small dev teams that want to focus entirely on code
  ✓ Apps with relatively stable, conventional traffic patterns

PaaS struggles with:
  ✗ Custom runtime or programming language needs not supported by the platform
  ✗ Low-level operating system configuration changes (OS-level customization)
  ✗ Long-running async background processes (background workers)
  ✗ Instant reaction to non-HTTP external events (e.g., triggers from storage file uploads)

PaaS’s main trade-off: you exchange control for operational convenience. If the application needs a native C++ system library that must be compiled into the OS, or needs custom communication protocols beyond HTTP/HTTPS, PaaS often can’t accommodate it. This flexibility gap is what later gave birth to the containerization era (Docker) and microservices.

Microservices and the Push for Modular Architecture #

Alongside infrastructure technology advances, software architecture also evolved from the monolith model (all features packaged into one giant application) toward microservices architecture (applications split into small, independent units).

The Transition from Monolith to Microservices #

flowchart TB
    subgraph Monolith[Monolith Architecture]
        M["Single Codebase<br/>All features in 1 app"]
    end

    subgraph Microservices[Microservices Architecture]
        S1["Service: Auth"]
        S2["Service: Catalog"]
        S3["Service: Order"]
        S4["Service: Payment"]
        S5["Service: Notification"]
    end

    Monolith -->|Decompose| Microservices

New Operational Challenges #

Splitting an application into dozens of independent microservices triggers new infrastructure complexity:

New Microservices Architecture Challenges:
  ✗ 10 services means managing 10 different deployment pipelines
  ✗ 50 services require 50 separate monitoring dashboards
  ✗ 100 services trigger high inter-service communication overhead
  ✗ Allocating a VM/server for each small service wastes money
  ✗ Difficulty coordinating dynamic scaling for each microservice

The industry began to realize that running one small service in its own dedicated VM/virtual server is financially and operationally inefficient. The engineering community needed a model where they could run the smallest unit of code instantly, without paying 24/7 server rental costs for services that are rarely invoked.

The Key Moment: The Birth of Function as a Service (FaaS) #

The year 2014 became the most important milestone for the serverless movement. Amazon Web Services introduced AWS Lambda at its annual AWS re:Invent conference, officially giving birth to a new compute category called Function as a Service (FaaS).

A Paradigm Shift in Code Execution #

Before FaaS, the developer mindset for deploying applications was:

“Run this application on a server continuously, then let the server wait for incoming requests.”

After FaaS was born, that mindset changed completely:

“Register this code function with the cloud platform. Let the platform handle the runtime, and run the code only when a specific event triggers it.”

sequenceDiagram
    participant User
    participant API Gateway
    participant Lambda
    participant S3

    User->>API Gateway: GET /image
    API Gateway->>Lambda: invoke function
    Lambda->>S3: get object
    S3-->>Lambda: image data
    Lambda-->>API Gateway: response
    API Gateway-->>User: 200 OK + image

    Note over Lambda: No server stays running.<br/>Lambda activates only when invoked,<br/>then shuts down as soon as it finishes.

FaaS Characteristics Compared to IaaS and PaaS #

FaaS Provider Evolution #

The AWS Lambda launch sparked fierce competition among the other cloud giants to offer similar FaaS services:

• 2014: AWS launched AWS Lambda (the commercial pioneer).
• 2016: Google introduced Google Cloud Functions and Microsoft launched Azure Functions.
• 2017: Cloudflare released Cloudflare Workers, executing serverless functions directly at edge locations closest to users.
• 2018: The open-source Knative project was launched by Google and an industry consortium to standardize serverless on top of Kubernetes.

Example FaaS Code Structure (JavaScript Node.js) #

A serverless function is designed to complete one specific task quickly.

// ANTI-PATTERN: A single function doing too many tasks (Monolith in FaaS)
exports.handler = async (event) => {
    const user = await getUserFromDB(event.id);
    await sendWelcomeEmail(user);
    await updateSearchIndex(user);
    await notifySlack(user);
    await generateInvoice(user);
    return { statusCode: 200, body: 'User processed' };
};

// CORRECT: Function focused on one specific task (Single Responsibility)
exports.handler = async (event) => {
    const user = await getUserFromDB(event.id);
    await sendWelcomeEmail(user);
    return { statusCode: 200, body: 'Email sent successfully' };
};

The golden rule of FaaS: a function must be stateless (not storing data in local memory between invocations), short (running in seconds), and idempotent (safe to run repeatedly with the same input without producing duplicate side effects).

The Evolution of the Modern “Serverless” Meaning #

Over time, the term “serverless” is no longer limited to FaaS (function compute). The meaning has been generalized to describe the entire category of cloud managed services that adopt the operational characteristics of server-free management.

The Modern Serverless Ecosystem #

Serverless application architecture can now be built end-to-end without involving traditional servers anywhere, thanks to the availability of these supporting services:

flowchart TD
    Root["Serverless Ecosystem"] --> Compute["Compute"]
    Compute --> Lambda["AWS Lambda"]
    Compute --> CF["Cloud Functions"]
    Compute --> AF["Azure Functions"]
    Compute --> CW["Cloudflare Workers"]

    Root --> DB["Database"]
    DB --> DynamoDB["DynamoDB"]
    DB --> Firestore["Firestore"]
    DB --> CosmosDB["Cosmos DB"]
    DB --> Aurora["Aurora Serverless"]

    Root --> Storage["Storage"]
    Storage --> S3["AWS S3"]
    Storage --> GCS["Cloud Storage"]
    Storage --> Blob["Blob Storage"]

    Root --> Msg["Messaging"]
    Msg --> SQS["SQS / SNS"]
    Msg --> PubSub["Pub/Sub"]
    Msg --> EventBridge["EventBridge"]

    Root --> Auth["Authentication"]
    Auth --> Cognito["Cognito"]
    Auth --> FireAuth["Firebase Auth"]
    Auth --> Auth0["Auth0"]

    Root --> Integration["Integration & Workflows"]
    Integration --> APIGW["API Gateway"]
    Integration --> StepFn["Step Functions"]
    Integration --> Workflows["Workflows"]

The Modern Definition: “No Operational Responsibility” #

The best industry-agreed definition of serverless today is:

# ANTI-PATTERN: "Serverless = no physical computers/servers"
# This understanding is wrong. Our code still runs on physical computers in cloud data centers.

# CORRECT: "Serverless = developers are freed from server management responsibility"
# The physical servers exist, but all the complexity of provisioning, maintenance, scaling, 
# and fault tolerance is fully handled by the cloud provider.

Serverless as the Logical Consequence of Evolution #

If we trace the historical line backwards, serverless is not an innovation that happened suddenly without pattern. It is the peak of a technology abstraction trend that has been consistently increasing for over 30 years.

The Technology Abstraction Trend Flow #

flowchart LR
    A["Higher<br/>Abstraction"] --> B["Lighter<br/>Operational Burden"]
    B --> C["Developers Focus on<br/>Business, Not Infra"]
    C --> D["Faster<br/>Time to Market"]
    D --> A

    style A stroke:#0080ff,stroke-width:2px
    style B stroke:#00bb00,stroke-width:2px
    style C stroke:#ffaa00,stroke-width:2px
    style D stroke:#ff00aa,stroke-width:2px

Through this history, we can see that every technology shift aims to remove infrastructure details that are irrelevant to business logic so products can reach the market much faster.

Summary #

• Serverless is the culmination of 30 years of infrastructure architecture evolution, moving from Physical Server → Virtual Machine (VM) → IaaS (Cloud VM) → PaaS (Managed Runtime) → FaaS/Serverless.
• The main problem it solves is server operational cost inefficiency caused by over-provisioning and the heavy burden of system administration (OS patching, manual scaling, hardware monitoring).
• The birth of AWS Lambda in 2014 introduced the FaaS (Function as a Service) model that executes code event-driven and on-demand, shifting the deployment unit from server/application level to the single function level.
• The modern definition of serverless doesn’t mean eliminating servers, but fully transferring all server management responsibility to the cloud provider.
• The serverless ecosystem now covers every application layer, from compute (FaaS & Containers), relational/NoSQL databases, messaging queues, user authentication, to file storage.