Google Jupiter: A Decade of Evolution in Hyperscale Datacenter Networking
Recently, Google Jupiter received the 2026 ACM SIGCOMM Networking Systems Award. This marks Google’s second major SIGCOMM systems recognition within five years, following the award-winning B4 WAN architecture in 2021.
More importantly, the award symbolizes the industry’s recognition of a broader transformation: hyperscale networking is no longer merely infrastructure. It has evolved into the computational backbone of modern cloud services and AI-scale systems.
This article systematically reviews Jupiter’s decade-long evolution, from its origins in traditional Ethernet datacenter networking to its transformation into one of the most influential hyperscale network architectures ever built.
🌐 Before Jupiter: Why Google Started Building Its Own Network #
Before 2005, Google’s datacenter network architecture looked similar to that of most internet companies:
- Purchase networking equipment from Cisco and Juniper
- Expand capacity by stacking bandwidth
- Rely on traditional distributed networking protocols
However, this model quickly exposed severe limitations at Google scale.
🔄 The Three Core Problems of Traditional Commercial Networking #
Commercial switches suffered from several structural issues:
Extremely High Cost #
As Google’s infrastructure rapidly expanded, networking costs scaled almost linearly with cluster growth.
Traditional networking vendors priced hardware aggressively, and scaling large Clos fabrics became economically unsustainable.
Operational Complexity #
Conventional distributed routing protocols introduced enormous operational overhead:
- Manual configuration
- Slow convergence
- Large failure domains
- Complex troubleshooting
At Google scale, traditional operational workflows simply did not scale.
Lack of Customization #
Commercial networking vendors built generic networking products.
They did not optimize for workloads such as:
- Search indexing
- Gmail synchronization
- Distributed storage
- Large-scale MapReduce traffic
Google realized it was being forced to adapt its infrastructure around vendor limitations rather than designing networking around its own workloads.
🏗️ The Pre-Jupiter Experimental Era #
Starting around 2005, Google began internally developing multiple generations of self-built datacenter networking systems:
- Firehose 1.0
- Firehose 1.1
- Watchtower
- Saturn
Each generation solved part of the scaling problem while exposing deeper architectural limitations.
By approximately 2011, Google reached a critical realization:
Incremental hardware patching was no longer enough. The entire network architecture had to be redesigned from first principles.
This realization directly led to the Jupiter project.
🚀 The Birth of Jupiter #
Google officially launched Jupiter in 2012.
At the time, hyperscale infrastructure faced three major industry bottlenecks.
Bandwidth Explosion #
Server network bandwidth was transitioning:
- From 10G
- Toward 40G
This pushed aggregate datacenter bandwidth requirements into the Pbps era.
Massive Server Scale #
Datacenter deployments were surpassing:
- 100,000 servers per facility
East-west traffic complexity increased dramatically.
Power and Operational Constraints #
Operators needed:
- Lower power consumption
- Easier maintenance
- Online scaling without downtime
Traditional architectures could not simultaneously satisfy all three goals.
Google therefore designed Jupiter around several core principles:
- Infinite horizontal scalability
- High bisection bandwidth
- Lower operational complexity
- Online incremental expansion
- Software-defined global traffic control
🧩 Google’s Four Major Networking Pillars #
Within Google’s infrastructure ecosystem, Jupiter represents only one component of a much larger architecture.
Google eventually built four foundational networking systems:
| System | Primary Role |
|---|---|
| Jupiter | Internal datacenter fabric |
| B4 | Global WAN traffic engineering |
| Andromeda | Cloud virtualization and networking |
| Espresso | Edge peering and external traffic management |
Together, these systems formed a fully integrated hyperscale networking stack spanning:
- Internal networking
- WAN transport
- Cloud infrastructure
- Global edge connectivity
📈 Phase 1: Jupiter 1.0 (2015) #
In 2015, Google published the landmark SIGCOMM paper:
Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network
This paper officially unveiled Jupiter’s first-generation architecture and immediately became one of the most influential datacenter networking designs in the industry.
🧱 Clos Topology at Massive Scale #
Jupiter 1.0 used a large-scale three-tier Clos topology.
The architecture consisted of:
Access Layer #
- Centauri Top-of-Rack (ToR) switches
- Direct server connectivity
Aggregation Layer #
- Traffic concentration
- Intermediate forwarding
Backbone Layer #
- High-density spine switches
- Full non-blocking interconnectivity
This architecture delivered:
- 1.3 Pbps total bidirectional bandwidth
- Stable support for 100,000 servers
- 10 Gbps per-server connectivity
At the time, these numbers were unprecedented.
🧠 The SDN Revolution #
The true innovation of Jupiter 1.0 was not merely scale.
It was the adoption of:
Centralized Software-Defined Networking (SDN)
Traditional distributed routing protocols were largely abandoned.
Instead:
- Central controllers managed global policy
- Configuration became centrally orchestrated
- Traffic engineering became globally optimized
This dramatically simplified operations.
Engineers no longer needed to configure thousands of switches individually.
Operational efficiency increased enormously.
⚡ Online Expansion Without Downtime #
One of Jupiter’s most important operational breakthroughs was:
Online incremental expansion
New networking hardware could be inserted into the fabric without interrupting production services.
Critical workloads such as:
- Search
- YouTube
- Gmail
could continue operating uninterrupted during network scaling operations.
This capability became foundational for hyperscale cloud infrastructure design.
📊 Jupiter 1.0 Technical Impact #
Compared with Google’s earlier architectures, Jupiter 1.0 achieved:
- 10× overall bandwidth increase
- 20% lower machine power consumption
- Far greater horizontal scalability
After publication, Clos+SDN rapidly became the dominant architecture across the cloud industry.
Major hyperscalers quickly adopted similar design philosophies.
🔄 Phase 2: Jupiter Evolving (2022) #
Between 2016 and 2022, cloud workloads expanded dramatically.
Simultaneously:
- Big data analytics
- AI training
- Distributed storage
- Hyperscale cloud services
pushed traditional electrical switching architectures toward their physical limits.
Google therefore initiated the next major Jupiter transformation.
🔦 Optical Circuit Switching (OCS) #
In 2022, Google published:
Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking
The paper revealed a major architectural shift:
Replacing electrical spine switching with Optical Circuit Switching (OCS)
🔍 MEMS Optical Switching #
Google introduced MEMS-based Optical Circuit Switches.
This enabled:
- Direct optical interconnectivity
- Fewer electrical conversions
- Lower latency
- Lower power consumption
Instead of relying entirely on fixed Clos paths, aggregation blocks could now establish direct optical connections dynamically.
This fundamentally altered datacenter topology behavior.
📉 Major Improvements #
The Jupiter Evolving architecture delivered enormous gains.
Bandwidth #
Total fabric bandwidth increased:
- From 1.3 Pbps
- To 6.4 Pbps
A roughly 5× improvement.
Cost Reduction #
Hardware procurement costs dropped by:
- 30%
Power Efficiency #
Operational power consumption fell by:
- 41%
Lower Latency #
Average forwarding path length decreased:
- From 2–3 hops
- To approximately 1.4 hops
Latency dropped into the microsecond range.
🧠 SDN Evolves Into Dynamic Topology Engineering #
Jupiter’s SDN layer also evolved significantly.
Earlier SDN generations primarily focused on:
- Traffic engineering
- Path management
The newer architecture introduced:
Dynamic topology engineering
The network could now:
- Reconfigure optical paths dynamically
- Adapt topology to workload demand
- Optimize fabric structure in near real-time
This marked the transition from:
Static networking
toward:
Programmable infrastructure fabrics
🤖 Jupiter’s Role in the AI Era #
Although Jupiter originally targeted hyperscale cloud workloads, its architectural importance exploded during the rise of AI infrastructure.
Large AI clusters fundamentally changed datacenter networking requirements.
Modern AI training workloads require:
- Massive east-west bandwidth
- Extremely low latency
- Deterministic congestion behavior
- High GPU utilization efficiency
In modern AI infrastructure:
Networking is no longer merely connectivity. Networking is part of the compute system itself.
Jupiter’s large-scale centralized traffic engineering and optical fabric optimization positioned Google extremely well for the AI era.
🔮 Why Jupiter Matters Historically #
Jupiter’s significance extends far beyond Google itself.
It fundamentally reshaped how the industry thinks about networking.
Before Jupiter #
Networking was viewed as:
- Hardware appliances
- Vendor-defined infrastructure
- Distributed control systems
After Jupiter #
Networking became:
- Software-defined
- Centrally orchestrated
- Horizontally scalable
- Closely integrated with compute systems
This philosophical shift influenced nearly every modern hyperscaler.
🏁 Conclusion #
Google Jupiter’s decade-long evolution reflects the broader transformation of hyperscale infrastructure itself.
The first generation proved that:
- Clos topology
- centralized SDN
- merchant silicon
could scale to unprecedented levels.
The second generation demonstrated that:
- optical switching
- dynamic topology engineering
- programmable fabrics
would define the future of datacenter networking.
Today, as AI infrastructure drives another industry-wide architectural transition, the ideas pioneered by Jupiter continue to influence how hyperscale systems are built worldwide.
More importantly, Jupiter established a principle that now defines modern infrastructure engineering:
At hyperscale, networking is no longer just infrastructure. It becomes part of the computing architecture itself.