Chapter 2: The History of RPC — From Sun RPC to gRPC

Understanding where gRPC came from helps you understand why it makes the design choices it does. Every feature in gRPC is a response to a problem encountered in earlier RPC systems.

The Idea: Make the Network Invisible (1976–1984)

The concept of RPC was formalized by Bruce Jay Nelson in his 1981 PhD thesis at Xerox PARC. The dream was simple: make calling a function on a remote machine look identical to calling a local function.

// The programmer writes this:
result = compute_tax(income, region);

// They don't care if compute_tax runs locally or on a machine 1000km away.
// The RPC framework handles: serialization, network, deserialization, errors.

This is called location transparency — the caller doesn't know (or care) where the function executes.

Sun RPC / ONC RPC (1984)

Sun Microsystems created the first widely-used RPC system. You still encounter it today — NFS (Network File System) is built on Sun RPC.

Key characteristics:

• XDR (External Data Representation) for serialization — a binary format
• rpcgen — a code generator that produces C stubs from an interface definition
• Port mapper — a service discovery mechanism (portmap/rpcbind)
• Worked over both TCP and UDP

DCE/RPC (1988) and DCOM (1993)

DCE/RPC (Distributed Computing Environment) was created by the Open Software Foundation. It introduced:

• UUIDs for interface identification (yes, UUIDs were invented for RPC!)
• IDL (Interface Definition Language) — a formal way to describe interfaces
• NDR (Network Data Representation) for serialization

Microsoft built DCOM (Distributed COM) on top of DCE/RPC. It powered Windows distributed computing in the 90s. If you've ever dealt with Windows COM objects, that's the legacy.

CORBA (1991)

The Object Management Group created CORBA (Common Object Request Broker Architecture). It was ambitious:

• Language-independent (C, C++, Java, Smalltalk, COBOL...)
• Platform-independent
• Used IIOP (Internet Inter-ORB Protocol) over TCP
• Had its own IDL

Why it failed: Incredibly complex. The spec was thousands of pages. Implementations were buggy and incompatible. Vendor lock-in was rampant. It became a cautionary tale of over-engineering.

Java RMI (1997)

Java's built-in RPC. Simple but Java-only. Showed that language-specific RPC is a dead end for heterogeneous systems.

XML-RPC → SOAP (1998–2000)

The web era brought XML-based RPC:

• XML-RPC (1998) — simple, XML over HTTP POST
• SOAP (2000) — XML-RPC on steroids. Added WSDL (interface definition), WS-Security, WS-ReliableMessaging, etc.

SOAP dominated enterprise computing for a decade. It worked, but:

• XML is verbose and slow to parse
• WSDL files were nightmarishly complex
• The WS-* standards stack became bloated
• Tooling was heavy (you needed IDE plugins just to generate clients)

REST (2000) — The Rebellion

Roy Fielding's PhD thesis described REST (Representational State Transfer). It wasn't RPC at all — it was a different paradigm based on resources and HTTP verbs. But it became the dominant API style because:

• Simple — just HTTP + JSON
• No code generation needed
• Human-readable
• Works in browsers
• Cacheable

REST won the public API war. But for internal microservice communication, its weaknesses showed:

• No formal contract (OpenAPI/Swagger came later, and it's optional)
• JSON is slow to serialize/deserialize
• HTTP/1.1 is inefficient (one request per connection, or head-of-line blocking)
• No streaming support
• Over-fetching and under-fetching problems

Thrift (2007) and Avro (2009)

Apache Thrift (Facebook) was a direct predecessor to gRPC's approach:

• IDL for service definition
• Binary serialization
• Code generation for multiple languages
• Multiple transport options

Apache Avro (Hadoop ecosystem) took a different approach — schema embedded with data, no code generation required.

Google Stubby (2001–2015, Internal)

Inside Google, Stubby handled all inter-service RPC from 2001 onwards. At its peak:

• ~10 billion RPC calls per second across Google's infrastructure
• Used Protocol Buffers for serialization (Protobuf was created for Stubby)
• Custom transport (not HTTP)
• Tight integration with Google's internal infrastructure

Stubby couldn't be open-sourced directly because it was deeply coupled to Google's internal systems. So they redesigned it on top of open standards (HTTP/2) and released it as gRPC in 2015.

gRPC (2015–Present)

gRPC took the best ideas from all predecessors:

Timeline Visualization

Why This History Matters

When you encounter gRPC design decisions that seem arbitrary, they usually trace back to a lesson learned from a predecessor:

• Why binary, not text? — SOAP/XML proved text is too slow at scale
• Why code generation? — REST proved that without contracts, APIs drift and break
• Why HTTP/2, not custom protocol? — Stubby's custom protocol couldn't traverse firewalls/proxies
• Why keep it simple? — CORBA proved that complexity kills adoption
• Why open-source? — DCOM/CORBA proved that vendor-controlled specs fragment