Contemplating the challenges and realities of hardware at the edge
Edge computing is, at its core, a distributed systems problem. Rather than dealing with a single application across a fleet of machines we have a fleet of applications across a fleet of machines, extending compute, data, and intelligence into the physical world.
In contrast to the cloud where it can be easy to stop thinking about architecture at the services level (containers, databases, messaging services), at the edge, no workloads are possible without hardware. Thus it becomes your responsibility to design, source, and service a fleet of thousands of diverse edge sites in a sustainable and maintainable manner while accounting for cost, reliability, form factor, and the other constraints of the edge.
In this post, we will introduce a simple framework for thinking about edge archetypes. We will walk through the key considerations.
Design
The first step is design, which considers the factors of hardware capability, cost, physical environment, and form factor.
Capability
What capability does an edge node really need? When thinking about edge device capability, it is prudent to consider what resources are necessary to execute on the primary workloads that are known today with room for linear growth and what additional use cases may emerge during the useful life of the device.
The key areas to consider are fairly obvious.
- Processor: What quality and speed of CPU and/or GPU is necessary? This can be answered by considering what workloads must run at the edge and what their needs are.
- RAM: How much RAM will your applications require? Does the physics of your physical environment require error-correcting RAM or shielding?
- Storage: Storage can be tricky. How much do you need? Key considerations are
- TPM: For most enterprise edge use cases, a TPM chip is essential in establishing a hardware root of trust and in assisting with the device identity attestation process during initial on-boarding.
- OpenBMC or IPMI Ports: Management ports can be very helpful in the event of a major in-field failure and are great insurance against the “massively distributed bricks” problem.
- Communications: Is the device an IOT Gateway that needs special antennas to support your desired communication protocols, or is it simply wired via ethernet?
When thinking about base capability, some head room is highly recommended. Beyond workload growth and scale, most environments are clustered, so it is also important to consider compute, RAM and storage resource buffers in the event of a device or switch port failure that will reduce node capacity. As a general rule of thumb, purchase the best hardware that you can anticipate fully utilizing over its lifecycle while preserving the ROI of the project. It is better to over-invest than under-invest; just avoid massive overinvestment.
Beyond the node selection process, you must also decide how many nodes you need. Also consider if you have power, switch port capacity, and budget tolerance for additional notes in the future if your plan is to solve for new use cases or growth with n+1 nodes.
It may be helpful to consider your capability needs and settle into one of these categories:
- Server-grade Hardware
- Industrial and Mini Computers
- IOT Gateway Devices
Cost
Like it or not, cost is a critical factor when selecting edge hardware. For organizations with hundreds, thousands, or tens-of-thousands of locations, the `nodes * cost-per-node * sites` number can get large very quickly.
We tend to see conservative investment in “just enough” hardware early in an organization’s edge compute lifecycle as the search for value takes place. As organizations experience the benefits of the edge, the budgets for reliable hardware architectures tend to follow.
At the same time, the early stage of the lifecycle can often be characterized by an “overbuild” characteristic of Apple: “we’ll overspec now and figure out what to do with it later”.
Finding the right balance between cost and capability is a challenge and will always require compromises. There is no perfect solution in a world with scarcity of resources. Start with capability needs, sell the business value, and back into a reasonable cost per site.
Form Factor
Many edge environments have constraints in available physical space driving importance into device form factor. While some environments have full racks, other edge environments occupy working office space or small shelves in closets. Selecting hardware that operates effectively in its available physical space is also a critical decision point. A very capable and cost effective device with nowhere to be deployed is not useful.
Physical Environment
What is the physical environment like? Is it extremely hot or cold? Are there particles in the air from production or manufacturing? Will the device be subject to physical conditions that require shielding or ECC memory? Considering the physical environment will also drive decisions such as selecting devices with or without fans or special shielding.
Power and Battery Backup
Finally, you must consider your power budget. How many watts are available for additional computers?
Beyond baseline power, battery backup is also a consideration. One common blind spots in edge design is assuming “battery backup already exists.” Many sites do, in fact, have facility-level UPS systems—but their runtime, load, or maintenance status may not match compute needs.
Some things to consider:
- How long must the edge environment run in the event of a power outage? Is it essential to business? Does the business operate for a period of time without power?
- Ensure the edge environment can shut down gracefully in the event of longer-term outage.
- Is there any final data that needs to be transmitted before the outage (if network is available too)?
Power design certainly isn’t glamorous—but it determines whether your distributed system recovers cleanly or corrupts data silently.
Source
Once capability, cost, and other factors are considered, hardware must be sourced. One of the first things to consider is whether to lease or buy devices.
Key Sourcing Considerations
- Lease vs Buy: which is best for your organization?
- Single vendor vs multi-vendor: many organizations prefer having multiple vendors for essential solutions. Edge Monsters generally recommends preferring homogeneity when possible as fewer SKUs are easier to manage, QA, and support. However, there are well-known architecture patterns for heterogeneous environments as they are often the norm, especially with brownfield deployments. As a general rule, we recommend targeting at most 3-4 reference configurations that will live in the field at any given time.
- Internal and External Compliance: The best hardware might be the hardware that you are cleared to use.
Service the Fleet
Once hundreds or thousands of edge sites are deployed in the field, operations discipline matters more than hardware specification selection. There are numerous paths to success in this area, but be sure to not overlook or underestimate the effort involved in doing this well. A weak service strategy or implementation will cripple even the best edge architecture.
When designing a service model, consider the following questions:
- What is the expected lifecycle of the hardware?
- How will refreshes be performed?
- How will capability be added (through refresh, n+1)?
- What support paths work best? Remotely managed, on-site, or both?
- What service models are necessary to support these?
There are several valid approaches to serving a fleet of edge devices. We tend to see smaller sites (restaurant locations, remote field deployments, etc) favor a self-service, plug-and-play, rapid replacement model with devices either available on standby or drop-shipped. Larger sites (manufacturing, distribution centers) are more likely to have a technician physically on site (or at least nearby) and can perform hot swaps on parts or devices directly.
It goes without saying that “rolling a truck/helicopter/plane” is a major ROI hit on an edge solution, so edge architectures should seek minimize the “technician-to-field” scenarios as much as possible through thoughtful architecture and service design.
Deploying additional on-site, pre-configured (or bootstrappable) devices is one strategy that can help mitigate emergency technician deployments. The presence of these fallback devices is often a function of operational criticality, remoteness of location (miles offshore, in a country with limited supply of parts) or lack of on-site talent. Cost is, of course, a factor as well.
In addition to on-site service, Out-of-Band management using IPMI / OpenBMC may also be used to recover from some hardware failure scenarios (those caused by configuration rather than physical failure).
Regardless of your constraints, be sure to take the field service seriously so that hardware challenges don’t eliminate the value of your edge platform.
Edge Archetypes
In summary, we find that not every edge site looks the same. Some fit under a counter. Others fill a warehouse. A useful way to reason about edge deployments, and thus how to think about hardware, is through archetypes—each with its own scale, cost, and service model.
| Archetype | Example | Scale | Typical Traits | Service Model |
|---|---|---|---|---|
| Micro / IoT Gateway | Smart sensors, small retail | Very small | Low cost, minimal compute, limited local storage | Plug-and-play, remote management only |
| Small / Retail Edge | Restaurant, small site | Small | 2-3 hosts, moderate compute and storage, constrained power and space | Light field service, replace-not-repair |
| Medium / Commercial Edge | DC, logistics node | Medium | 1 controller, medium compute cluster, optional GPU | Field tech support, planned maintenance |
| Large / Industrial Edge | Manufacturing, warehouse | Large | Multiple racks, redundant power and cooling, dedicated IT | Traditional datacenter operations |
This t-shirt sizing approach—small, medium, large—simplifies lifecycle planning. It enables policy-based provisioning, cost optimization, and consistent lifecycle management across diverse locations.
Closing Thought
Edge architectures succeed when they balance technical ambition with operational reality. Establish your target archetype, consider all the elements of hardware support, adjust to your business’ needs, and ship. You will learn more in the field than from this article, but by addressing these concerns up front, you will avoid the key pitfalls of massively scaled hardware and be set up for success in your business and at the edge.
Be sure to subscribe for updates and follow us on LinkedIn.
The Edge Monsters: Jim Beyers, Colin Breck, Brian Chambers, Tilly Gilbert, Michael Henry, Michael Maxey, Chris Milliet, Erik Nordmark, Joe Pearson, Steve Savage, Jim Teal, & Dillon TenBrink.
