ARM in the Cloud: Project Olympus and Centriq 2400 in 2017

Microsoft’s cloud hardware playbook took a visible step off the x86 roadmap in 2017 when the company publicly embraced ARM-based server designs — demonstrating Qualcomm’s Centriq 2400 on Project Olympus motherboards at the Open Compute Project summit and confirming Azure had ported key server components to run on ARM for internal testing and future deployment scenarios. (azure.microsoft.com) (investor.qualcomm.com)

Background​

Microsoft’s Project Olympus is an open, modular server reference designed to give hyperscale cloud operators flexibility in compute, networking, and power. The Project Olympus designs — contributed to the Open Compute Project (OCP) — explicitly include support for ARM-based motherboards from vendors such as Qualcomm and Cavium, and Microsoft used OCP Summit demonstrations in 2017 to show Windows Server and Azure components running on ARM silicon for internal evaluation. (opencompute.org)
Qualcomm’s response to that ecosystem push was the Centriq 2400 family: a high-core-count, ARMv8-compatible server SoC manufactured on Samsung’s 10 nm FinFET process, with up to 48 custom Falkor cores, a large on-die cache pool, six-channel DDR4 memory support and a focus on throughput-per-watt for scale-out cloud workloads. Qualcomm’s announcements and technical briefings framed Centriq as a purpose-built cloud CPU that Microsoft and other cloud players could adopt into Project Olympus-style 1U and 2U servers. (investor.qualcomm.com)

---

What was announced (the facts)​

• Microsoft confirmed at the OCP US Summit in March 2017 that it had ported Windows Server for internal use to run on ARM-based servers, and that Qualcomm and Cavium motherboards were part of the Project Olympus contributions. Microsoft explicitly characterized the ARM effort as an internal optimization and part of the open-hardware ecosystem work. (azure.microsoft.com, datacenterdynamics.com)
• Qualcomm publicly launched and began shipping the Centriq 2400 series in 2017, positioning it as the industry’s first 10 nm server processor, with up to 48 Falkor cores, a distributed 60 MB L3 cache, 6-channel DDR4 memory, and power consumption targeted under 120 W for the top SKUs. Qualcomm listed Microsoft Azure among the partners demonstrating the platform at the Centriq events. (investor.qualcomm.com, electronicsweekly.com)
• The Centriq motherboard specifications submitted to OCP were designed to be compliant with Microsoft’s Project Olympus modular server blueprint, enabling OEMs/ODMs to build universal motherboards that host ARM or x86 CPUs interchangeably within the same mechanical and rack-level ecosystem. (investor.qualcomm.com, opencompute.org)

These are verifiable, contemporaneous statements from the companies and OCP summaries that were publicly documented at the time. Where reporting or secondary coverage introduced technical errors, those have been corrected below.

---

Corrections and caution: what some early reports got wrong​

Multiple outlets repeated a mis-typed or mistranslated value claiming a “2400nm FinFET” process; that number is physically impossible for modern CPUs and appears to be a transliteration error. Qualcomm’s documentation and press releases clearly state that Centriq 2400 was built on a Samsung 10 nm FinFET process — not 2400 nm. Always treat stray numeric labels with skepticism and verify against vendor datasheets. (investor.qualcomm.com)
Another common source-of-confusion: Microsoft’s demonstration of Windows Server on ARM was explicitly for internal use and ecosystem enablement — not an announcement that Windows Server or Azure public VMs were immediately available to customers on ARM in the same fashion as existing x86 offerings. Microsoft has historically differentiated internal platform testing from production public rollout decisions; the company noted future deployment plans but did not declare blanket production availability for every Azure service on ARM at that time. (azure.microsoft.com)

---

Technical strengths: why Microsoft and partners pursued ARM​

ARM architecture offered several compelling technical and economic upsides for cloud-scale scenarios in 2017 — and many of these rationales remain relevant today:

• Performance-per-watt: Centriq’s design prioritized energy efficiency for highly threaded, throughput-oriented workloads (web front-ends, microservices, NoSQL stores). 10 nm process density plus a high core count aimed to lower power consumption per unit of work versus some contemporary Xeon parts. (investor.qualcomm.com)
• Scale-out economics: Cloud-native services benefit from scale-out designs where many modest cores can be aggregated into large clusters. ARM’s efficient cores make per-instance economics attractive for horizontal workloads. Qualcomm explicitly pitched Centriq at throughput and price-performance for scale-out cloud workloads. (cnx-software.com)
• Open hardware compatibility: Project Olympus’ modular Universal Motherboard concept gave Microsoft the ability to define mechanical and electrical interfaces so OEMs could deliver the same rack populated with different compute bricks — x86, ARM, or accelerators — without redesigning racks or power distribution. This lowers integration friction and improves lifecycle management. (opencompute.org)
• Ecosystem enablement: Qualcomm invested in porting hypervisors, Linux distributions, and key middleware; Microsoft and other partners demonstrated common cloud workloads (Kubernetes, Docker, MongoDB, Redis, etc.) running on Centriq hardware during the launch and OCP events. That ecosystem work is essential because software — not raw silicon — determines the pace of real-world adoption. (investor.qualcomm.com, cnx-software.com)

---

Material limitations and risks​

While the engineering case for ARM in the cloud is strong, the business and operational realities presented meaningful headwinds.

Software and compatibility friction​

Microsoft’s port of Windows Server to ARM was a proof of concept for internal Azure services, not a guarantee of parity for every workload. For many enterprise services, vendors and ISVs still relied on x86 binaries and ecosystem tooling. Porting, optimizing, and validating Windows-dependent enterprise stacks across different ISAs is expensive and slow — and that friction raises the cost of switching to ARM-based hosts for many customers. (azure.microsoft.com)

Ecosystem and tooling fragmentation​

A large and mature x86 software ecosystem made it easier for enterprises to “lift and shift” to cloud VMs that used familiar processor families. ARM introduced new permutations — different microarchitectures, cache hierarchies, and vendor-specific extensions — and that variability creates testing overhead for cloud consumers pursuing multi-architecture portability. Fragmentation risk is real if every hyperscaler adopts different Arm cores or custom ISAs.

Supply chain and vendor risk​

Qualcomm’s datacenter experiment was short-lived as a broad commercial challenge to Intel. After initial Centriq launches and demonstrations, Qualcomm trimmed the datacenter business and wound down investments — ultimately pausing or exiting the direct server CPU pursuit by late 2018. That decision left customers and cloud partners with uncertainty about long-term silicon roadmaps and support for Centriq-grade platforms. The viability of an ARM server strategy depends not just on engineering wins but on a sustained supplier ecosystem and multiple silicon choices. (networkworld.com, datacenterknowledge.com)

Cost vs. performance tradeoffs​

Benchmarks at the time showed compelling price-performance in targeted workloads, but raw single-thread CPU performance and high-performance compute (HPC) workloads often still favored x86 designs. That meant ARM value propositions were stronger in scale-out microservice workloads and weaker for latency-sensitive, monolithic applications that require high single-thread throughput. Choosing ARM therefore required workload-level analysis. (investor.qualcomm.com, cnx-software.com)

---

What actually happened after the 2017 demonstrations​

Qualcomm publicly shipped Centriq 2400 in late 2017 and showcased arrays of ecosystem partners — but the follow-through into broad commercial production was limited. By 2018 Qualcomm had begun scaling back investment in the data center CPU group; leadership departures and layoffs followed, and Qualcomm repositioned the unit around specific customers and partnerships rather than a general-purpose data center business. Industry reporting and post-mortems concluded the unit faced structural market headwinds, intense competition from AMD and Intel, and corporate strategic shifts that deprioritized the server line. (investor.qualcomm.com, nasdaq.com, axios.com)
Microsoft and other cloud operators continued to explore ARM options — but the ecosystem matured in different directions. Over subsequent years, hyperscalers invested in custom Arm designs (notably AWS with Graviton and later Google and Microsoft making their own custom silicon and strategic partnerships), and Microsoft itself advanced its ARM investments and internal silicon initiatives in subsequent product cycles. The archival forum and product traces indicate Microsoft continued pursuing Arm-based VM work and later internal custom silicon efforts that extended the original intent behind Project Olympus experimentation.

---

Why Project Olympus mattered (and still matters)​

Project Olympus did two distinct but related things:

• It created a common mechanical, electrical, and firmware baseline that made it easier to try different CPU architectures in the same rack design.
• It signaled a hyperscale mindset: treat hardware design like open-source software — share reference designs, encourage multiple silicon suppliers, and accelerate interoperability.

That approach reduces vendor lock-in at the rack level, accelerates validation for new architectures (including ARM), and lowers the cost of innovation for cloud operators and their suppliers. Microsoft’s Project Olympus contribution remains a template for how hyperscale players can iterate on hardware at cloud-speed. (opencompute.org)

---

Practical implications for enterprise IT and cloud architects​

If your organization is evaluating Microsoft Azure (or any cloud provider) and wondering what the ARM-for-servers move means in practice, here’s a pragmatic checklist:

• Assess workload characteristics:
• Determine whether your applications are scale-out microservices (great candidates for Arm cost-efficiency) or latency-sensitive/HPC (likely better on high-frequency x86 parts).
• Validate software compatibility:
• Inventory third-party binaries, libraries, and drivers. Confirm Arm64 or multi-arch support from ISVs for any critical stack components.
• Embrace containerization and CI/CD for multi-arch builds:
• Adopt multi-arch container images and build pipelines that produce both AMD64 and Arm64 artifacts to preserve portability.
• Benchmark for total cost of ownership:
• Measure not just raw CPU cost but energy consumption, licensing, operational overhead, and engineering resources required for porting/validation.
• Plan for vendor and roadmap risk:
• Avoid single-supplier dependency. Track vendor roadmaps closely and prioritize flexibility in procurement contracts.
• Start small and iterate:
• Use non-critical services for Arm pilot tests, measure real-world gains, and plan migration windows based on empirical data.

These steps reduce migration surprises and allow architects to capture ARM’s efficiency wins when appropriate.

---

A critical look: strategic gains vs. execution headwinds​

Microsoft’s embrace of ARM server hardware in 2017 was strategically correct: hyperscalers should own the right to pick the best compute fabric for each workload. Project Olympus lowered the barrier to experimentation and made it easier for software and silicon partners to participate. Qualcomm’s Centriq 2400 proved the hardware-level feasibility of a high-core-count 10 nm ARM server SoC and validated many of the performance-per-watt claims for cloud-native workloads. (opencompute.org, investor.qualcomm.com)
However, the real-world outcome underlined a core truth: silicon innovation is necessary but not sufficient. Long-term market success requires matching engineering wins with sustained investments, a broad partner ecosystem (OS, hypervisors, ISVs), manufacturable economics, and a business model that survives corporate reprioritization. Qualcomm’s retrenchment showed how fragile that value chain can be, even when the technical arguments are solid. (datacenterknowledge.com)

---

Lessons for cloud and hardware vendors​

• For cloud providers: maintain architectural neutrality. Offer customers choice across architectures and ensure developer tooling and managed services are consistent across underlying silicon.
• For silicon vendors: beyond delivering a strong SoC, prioritize ecosystem partnerships (OS, virtualization, management, drivers) and secure long-term OEM/ODM commitments before expecting hyperscale adoption.
• For enterprises: treat ARM as an opportunity — not an immediate universal replacement. Start with greenfield and containerized workloads and measure economics comprehensively.

---

The long arc: where ARM in the cloud went after Centriq​

The Centriq episode was a key early moment in a longer trend: hyperscalers increasingly embraced custom or alternative silicon to optimize price-performance and energy efficiency. AWS’s Graviton family became a major commercial success for specific workloads; other cloud players pursued custom designs or close partnerships with silicon vendors. Microsoft’s later in-house ARM work — evident in subsequent Azure product threads and platform announcements — demonstrates the original Project Olympus experiments matured into broader, more vertically integrated silicon strategies across the industry. Archive traces from community and platform discussions show Microsoft continuing the ARM conversation after Centriq, and later product developments reflect a multi-pronged approach to Arm in Azure.

---

Recommendations for Windows and Azure users today​

• Keep an eye on Azure VM families and regional rollouts: ARM-based instances can offer substantial cost and energy advantages for modern workloads, but availability and feature parity vary by region and service tier.
• Test on representative production-like workloads: real-world I/O patterns, garbage collection behaviour (for Java/.NET workloads), and network stacks often reveal performance differences that synthetic benchmarks miss.
• Prioritize multi-architecture CI and observability: build test suites that run across AMD64 and Arm64, and instrument telemetry to capture tail latencies and power consumption.
• Watch vendor roadmaps: silicon suppliers evolve quickly; monitor announcements from Microsoft, Arm partners, and major OEMs to align procurement and migration plans.

---

Conclusion​

Microsoft’s 2017 public move to include ARM-based server motherboards in Project Olympus and to demonstrate Windows Server running on Qualcomm’s Centriq 2400 was an important, visible push toward architectural choice at hyperscale. The technical promise was real: high core counts, modern 10 nm process nodes, and a design optimized for throughput and efficiency made Centriq an intriguing alternative for cloud-native, scale-out workloads. (investor.qualcomm.com, opencompute.org)
At the same time, the Centriq story underscores a central lesson for cloud-era hardware: silicon design must be matched by a durable ecosystem and a supplier strategy that survives corporate shifts. Qualcomm’s retreat from the server CPU business showed how business reality can curtail technically compelling projects. The broader architectural decision Microsoft made — to design open, modular hardware (Project Olympus) and to enable multiple silicon paths — however, remains a significant enabler for cloud agility. For architects and IT leaders, the enduring takeaway is to design for choice and portability: when the industry cycles through new silicon generations, the organizations that can flexibly move workloads and maintain consistent tooling will capture the efficiency gains while avoiding supplier-specific risk. (opencompute.org, networkworld.com)

---

Source: Mashdigi Microsoft adopts ARM architecture design for its servers for the first time to accelerate cloud services