From ARPANET to Service Mesh: How Network Architecture Evolved Over the Ages

Original Era

In November 1969, the US Department of Defense's ARPA created the ARPANET with four nodes to facilitate resource sharing among universities.

One year later the network grew to 15 nodes, and roughly every twenty days a large computer joined.

As the network expanded globally, different regions formed their own networks that spoke

different dialects

, making inter‑network communication impossible.

At that time machines communicated by mutually agreed conventions.

Machines had to handle packet loss, reordering, retries, and other issues themselves.

Bronze Era

To solve inter‑regional incompatibility, in 1973 two young engineers developed a universal communication method—TCP/IP—replacing the “dialects” with a common “Mandarin”.

With TCP/IP’s adoption, a large Internet formed.

TCP/IP ensured reliable transmission, allowing developers to focus on business logic.

Golden Era

Initially, applications were simple data‑transfer tools. The rise of the Web introduced many application‑layer protocols, spawning Chinese internet giants such as Tencent, Sina, Sohu, and Taobao.

Traffic was modest, and monolithic architectures sufficed.

Services had unique IP addresses and communicated via IP routing.

Platinum Era

Growing user numbers overwhelmed single instances, leading to clusters of multiple instances per machine and the introduction of load balancers to distribute traffic.

Diamond Era

Explosive traffic made horizontal scaling hit limits; monoliths grew large, coupling increased, and a single code change could affect the whole system.

The solution was microservices, splitting a business service into multiple independent services.

In a monolith, Service1 calls Service2 directly; in microservices, the call traverses the network.

Star Era

High availability demands led to hundreds of instances for critical services, increasing operational burden. Manual scaling became error‑prone.

First‑generation microservice frameworks emerged.

Each microservice embedded a proxy for registration and discovery, exemplified by Alibaba’s Dubbo and Weibo’s Motan, but these coupled services tightly and lacked multi‑language support.

King Era

To address those shortcomings, a new generation deployed a separate proxy process per host, shared by multiple microservices, handling service discovery and load balancing.

This pattern is known as the “sidecar” model, analogous to a motorcycle with a side trailer.

In modern Service Mesh architectures, both consumers and providers run a sidecar.

The sidecars manage registration, discovery, circuit breaking, rate limiting, and other governance functions, forming a service mesh.

Service mesh is an infrastructure layer that handles service‑to‑service communication. Cloud‑native applications have complex topologies, and a service mesh ensures reliable request traversal. It typically consists of lightweight network proxies deployed alongside applications, transparent to the apps.

Summary

Service Mesh characteristics:

Scenario: communication and governance between microservices

Solution: sidecar pattern

Positioning: infrastructure layer

Service mesh is a relatively new architectural style; choose technologies that fit your business needs rather than chasing trends.