Pragmatic Puzzles: Exploring Modular System Components

Introduction

OpenSFF is a nonprofit organization developing an open hardware standard for small form factor systems. In developing our modular architecture, we did not set out to ask, “Can we make this component modular?” With enough resources, nearly any component can be made independently serviceable or swappable: the processor, RAM, storage, power supply, etc. Even motherboards can be modular. But there is always a tradeoff. Every modular boundary requires connectors, retention hardware, power delivery paths, and many other supporting components that must be designed or sourced and then validated.

In this article, we are going to ask the more relevant question: “Which components are worth the cost of modularity?” We will go over the reasons why vendors design modular systems, how they achieve those goals, and what we decided to decouple.

Why make a modular system?

Modularity is a multidimensional characteristic. Depending on the component and the system it goes into, vendors and their users can benefit from independently swappable components in a number of ways.

Sustainability

Different parts of a system age at different rates. Whether it is an all-in-one workstation, an enterprise server, or an edge device, it is easy to foresee a device’s processor becoming obsolete in three to five years. But the chassis and several other components often remain usable if not highly suited for the entirety of a system’s lifespan. Making the system modular means we will not be forced to replace or discard the entire device because of one subpar part.

Serviceability and availability

Hot-swappable components such as storage drives or cooling fans can be replaced while the rest of the system keeps running. Entire processing units or servers can also be modularized for high availability.

Product variety

A single design can serve as the foundation for several products. A shared connector can allow multiple tiers of a part to work in one platform, which means end users can choose the component that fits their needs or budget.

Flexibility and scalability

Even when we have plenty of resources for a top-of-the-line system, modularity can still be desirable because it opens the door to customization. Third-party parts and accessories can extend or enhance what a system can do or look like, sometimes even beyond the vendor’s expectations. We see this all the time in DIY PC builds that have custom cooling loops and cases. In enterprise systems, faster or higher capacity drives can help extend the usefulness of decades-old chassis.

These motivations do not always apply equally to every component. But they do make it easier for vendors to decide which of their product’s parts should be modular.

Which components are typically modularized?

Short-lived core technologies

By “short-lived”, we are not just talking about parts that are prone to failure, though that is indeed a major reason to make a component independently replaceable. But we should also consider the parts that evolve the fastest: storage, processors, and RAM.

It is easy enough to understand why storage has been modular for decades. Consumer systems have long had 3.5” and 2.5” drive bays, and the past decade has seen M.2 slots become ubiquitous. Every couple of years, drive vendors release faster, higher capacity, and more durable products.

We are also seeing NAS devices add more modularity on top of their hot-swap drive bays. Minisforum recently released a line of NAS devices whose system board slides out simply by disengaging a pair of screws, making it easier to replace the boot SSD and RAM.

In enterprise servers, the recent big breakthrough is the Enterprise and Datacenter Standard Form Factor (EDSFF), a family of hot-swappable and easily accessible SSDs that share the same connector.

Meanwhile, the recent progress with processor and RAM technology is more interesting in terms of modularity. A growing number of processors are being paired with Low-Power Double Data Rate (LPDDR) memory, which is soldered directly onto the system board. LPDDR is designed to operate at lower voltages; the shorter connection to the CPU allows mobile devices, laptops, and even desktop-grade systems to enjoy that power efficiency while maintaining signal integrity.

Thankfully, the industry is finding ways to keep memory fast and modular. Low-Power Compression-Attached Memory Module (LPCAMM2) is a new memory standard that packages LPDDR memory in a removable board. Since it screws flat onto the system board, it is also much smaller and runs cooler than the familiar swappable DDR RAM module.

Long-lasting supporting infrastructure

These are the components that can easily outlive generations of compute: chassis, power supplies, fans, backplane hardware, or even displays. Separating them from the components in the previous category allows them to remain deployed rather than discarded.

As we explored in our article on modular consumer devices, companies that strongly support right-to-repair go to great lengths to make long-lasting parts modular. Alongside user-replaceable mainboards, storage, and memory, Framework and MNT products also have replaceable displays, keyboards, and even individual ports.

DIY desktop PC users have long enjoyed this kind of modularity. They can choose from many cases, power supplies, AIO coolers, and even power cables, and retain or reuse these components as their build evolves.

When it comes to enterprise hardware, hot-swappable PSUs and fans make maintenance quick and simple. That said, high-performance fans have become so reliable that some users are willing to forgo hot-swappable fans for more affordable or power-efficient hardware. But there are some components where it is not as easy to call for or implement modularity.

Specialized components

These are often components that involve a specific system topology. Examples include a storage controller for drive bays or a microcontroller running a managed switch. Components that are typically designed as PCIe expansion cards can also fall in this category. But there are two recent examples in the server world that show that it is possible for specialized components to be modularized.

The management controller in servers used to only be embedded directly on the motherboard. But the Open Compute Project’s Datacenter Secure Control Module (DC-SCM), introduced in 2020, turns the component into a pluggable card. The network interface is another specialized component that the Open Compute Project modularized. OCP NIC 3.0 replaces the proprietary mezzanine network cards of server vendors with a family of cards that share a card-edge connector and form factor.

Now that we have laid out the reasons for modularity and examples of modular implementations, let us go over our standard’s take on modularity.

OpenSFF’s modular boundaries

Our specifications transpose the modular architecture of blade servers to smaller scale implementations. We define three components: a processing module called the Compute Node, an electronic housing for one or more nodes called the Enclosure, and an optional node management unit called the Management Module. These components can be combined to create a variety of systems, from servers to industrial IoT devices, regardless of their vendors.

Beyond decoupling compute, management, and the housing, we encourage vendors to use serviceable parts when it is practical. We also ask vendors to use retention mechanisms that do not require specialized tools.

Establishing an open standard allows us to enhance the benefits of modularity. We have seen how proprietary modular solutions can actually work against sustainability and flexibility. If a swappable component can only be acquired from one vendor, we are limited by the variety and quantity that the vendor decides to release. We risk being stuck with hardware that we cannot repair or reuse if the vendor decides to move on to a new product line or stops providing support.

By allowing any vendor to create OpenSFF-compatible modules and defining those modules to be interoperable, users will have plenty of sourcing and replacement options. OpenSFF-compatible systems will have more opportunities to be reconfigured, repaired, or reused over their lifetime.

Why does OpenSFF not mandate component modularity?

We establish modularity at the system level. The Compute Node and the Management Module are modular, but the components inside the modules do not have to be. Requiring vendors to go all in on modularity down to the component level might seem like it will be more consumer-friendly and lead to systems that are more serviceable, customizable, and longer-lasting. However, doing so would impose additional constraints on our platform, specifically when it comes to flexibility and cost.

For instance, mandating modular memory takes away the opportunity from vendors to create low-cost, low-power nodes that function perfectly fine on soldered memory. There could be Full-featured Management Modules—variants that have their own CPU—that can get by with an eMMC chip for storage. Forcing vendors to use only modular components further reduces their freedom to optimize and differentiate within our standard’s other constraints.

Build with OpenSFF

It may be possible to make a system where every component is modular. But that would not necessarily be an objectively better system than one that has fixed or sealed parts.

Every modular boundary introduces design, engineering, and product constraints. Our goal, therefore, is not to maximize the number of removable components, but to place the boundaries where they provide the most value.

OpenSFF takes this approach at the system level. The Compute Node is a standardized, replaceable computing unit, while the Enclosure provides the infrastructure around it. What happens inside the node remains largely up to the manufacturer—the processor, memory, storage, PCB, and thermal solution do not need to follow a single standardized implementation. This leaves vendors room to optimize their designs while giving users a defined interface to replace the computing unit itself.

Modularity is not always about making everything removable. Looking at it from a system or ecosystem perspective, it can be about deciding what should be allowed to be changed independently.

If you would like to collaborate with us, we encourage you to read our specifications and to reach out to our development team at [email protected]. We would also be grateful if you spread the word about OpenSFF.