From LAN to Serverless: The Evolution of IT Infrastructure and Cloud Computing

A new technology does not appear out of nowhere; it inherits and develops from existing foundations. Serverless is no exception—reviewing the evolution of IT infrastructure shows that Serverless naturally emerges, though you can imagine it but cannot implement it yourself.

1. LAN Era

In the 1990s, an IT department needed to build an information‑management system. Systems were LAN‑based, using a client/server (C/S) model where business logic lived in client software that had to be installed on each computer and accessed a shared database.

Set up a LAN by purchasing switches and routers.

Buy servers and install operating systems such as Windows NT.

Install database software like Oracle.

Deploy client applications written in Delphi, VB, or PowerBuilder to each workstation.

2. Data Center

The C/S model suffers from major drawbacks: client updates are cumbersome, DLL‑hell issues arise, and server capacity is limited. With the rise of the Web, applications shifted to a browser/server (B/S) model, requiring servers hosted in data centers.

In a data‑center you must purchase servers, pay for network bandwidth, and install software such as Linux, Tomcat, Nginx, MySQL, etc. As functionality grows, additional servers are needed for caching, search, distributed processing, load balancing, and data replication, making self‑operated infrastructure increasingly complex.

3. Virtualization

Physical servers become wasteful when traffic drops. Companies like Amazon offered virtual machines—what we now call cloud computing—allowing users to request CPU, memory, and storage on demand without buying hardware.

No need to purchase physical servers; you simply request a VM with the desired specifications.

The operating system is installed automatically, and network bandwidth can be bought as needed.

Billing is pay‑per‑use, but you still pay even if no one accesses your application.

4. Ideal Model

The solution that emerges is to upload code directly to the cloud and run it on demand, charging only for actual CPU time and memory usage. If there is no traffic, the application is not deployed; when traffic arrives, the code is quickly deployed, executed, and then unloaded.

This “run‑when‑needed, go‑away‑when‑idle” approach eliminates the need to plan hardware, install software, or maintain servers.

However, deploying an entire application per request is impractical. Microservices are still too coarse‑grained; the appropriate granularity is a single function that does one thing, is stateless, and can start and stop quickly.

5. Characteristics of Serverless

Development and runtime flow:

Programmer writes a function.

Upload the function to a Serverless platform and define trigger rules.

When a request arrives, the platform loads the function, creates an instance, and runs it.

If traffic is high, instances scale out; if low, they scale in; if idle, they are unloaded.

A dispatcher is required to route requests to the correct function. Because functions are stateless, any persistent data must be stored externally (e.g., Redis, MySQL), which is essentially Backend‑as‑a‑Service (BaaS).

Serverless is best suited for stateless workloads such as image/video processing, format conversion, and IoT data handling.

In summary, Serverless abstracts away servers, providing on‑demand scaling, automatic provisioning, and usage‑based billing, but it requires applications to be decomposed into stateless functions and to rely on external services for any persistent state.