Red Hat edge platforms: Choosing the right one for your use case

Choosing the right platform for an edge deployment is one of the most consequential decisions an organization makes—and one of the most confusing. The options range from a single-board computer running a handful of containers to a full Kubernetes cluster with high availability, software-defined storage, and centralized management. Pick too small, and you hit a wall when requirements grow. Pick too large, and you waste budget, power, and operational effort on capabilities you don't need.

In 2023, we launched our initial series on edge computing with Red Hat. Part 1 of our original series, What is edge computing and what makes it so different?, provides a solid foundation for new edge architects. If you haven't read it yet, I recommend starting there.

Edge hardware options and platform topologies have evolved significantly since then: new OpenShift topologies, new management tools, and a clearer picture of where each option fits.

This new series is your guide to making that platform decision:

• Part 1 (this post): Red Hat Enterprise Linux and Red Hat Device Edge—including when Kubernetes makes sense and when it doesn't
• Part 2: OpenShift topologies—from single node to the new 2-node high-availability architectures
• Part 3: Management—how to keep your edge fleet running at scale

Platforms overview

If you're short on time, here's the quick reference. The rest of this series provides the detail behind each row.

There's no single solution that fits all needs. Red Hat offers a wide range of platforms to address different requirements and constraints. We distinguish between 2 main categories, depending on what the base is: Red Hat Enterprise Linux and Red Hat OpenShift. Each category supports a range of deployment topologies tailored to different requirements.

Red Hat platforms are agnostic to the type of workload—they can be modern, containerized workloads or more traditional virtual machines (VMs).

For example, you can run a VM and a single container happily coexisting with Red Hat Device Edge using Podman and KVM. Or a whole bunch of VMs (maybe stemming from a golden monolith) mixed with scaled-out container deployments (from microservices solutions) using OpenShift. This provides a platform supporting both traditional and modern workload types.

Figure 1 depicts the options, sorted from left to right by growing size, hardware, and resource requirements.

Note it's not either/or—a mixture of the 2 can help address many of those requirements and constraints. And there's intentional overlap between them. This lets you start on 1 platform and grow into the other. For example, start on the far edge or device side and connect those to the cloud, or reach out from hybrid cloud to edge.

Managing hundreds of disconnected edge nodes creates unique operational challenges. Part 3 of this blog series will cover centralized fleet management strategies in depth.

At Red Hat, the foundation of every solution is, of course, Red Hat Enterprise Linux (RHEL). Let's take a look at that now.

Red Hat Enterprise Linux and Red Hat Device Edge

The base of all edge deployments is a trusted operating system. Red Hat has a long-standing history in that domain. Hence, Red Hat Enterprise Linux is at the core of every edge deployment. In recent years, we added special capabilities designed for edge deployments.

RHEL-based deployments target small-form-factor edge devices operating in remote locations with limited hardware, intermittent power, and restricted connectivity. This allows solution builders to take full control of hardware, the operating system, and the application platform to create a tailor-made, highly optimized solution that solves their specific needs.

The main features of RHEL relevant for edge deployments are as follows.

Image-based deployments

Using image mode for RHEL (bootc), IT departments build the operating system as a standard container image using familiar Containerfile or Dockerfile workflows. That image is built once and then distributed to all edge locations—reducing deployment time and minimizing errors inherent in manual workflows. For existing rpm-ostree deployments, migration to bootc is supported without reinstallation (RHEL 9.6+).

Transactional updates with intelligent rollbacks

Updates are staged and applied atomically—either by rebooting into the new image or, with RHEL 10's soft reboot, by swapping user space in seconds without a full reboot. Health checks validate success and automatically revert to the last working state in case of errors.

Efficient over-the-air updates

Container layer caching and delta mechanisms minimize the amount of data that needs to be transferred to hundreds or thousands of remote nodes.

Fully self-contained deployments

Using image mode for RHEL (bootc), everything can be included in a single container image distributed to edge locations. This works really well for air-gapped, disconnected, or offline sites. For example, the image can be installed on a USB stick, brought to the device, and installed within minutes. No further connectivity is required. Updates are handled similarly; flash the new image onto the USB stick and bring that to the device. Instead of a USB stick, you can, of course, do the same via network if that's available.

Dependency pre-resolution

An additional benefit of image-based deployments is that resolving and downloading dependencies happens once during build time at the central location, instead of in every single edge installation. That saves bandwidth, time, and CPU cycles during deployment at the edge site, and helps maintain consistency.

RHEL workloads can be traditional RPM-based applications, virtual machines using KVM, or containers using Podman.

Commercially, RHEL-based options are available in 2 flavors: pure RHEL, which is the operating system, and Red Hat Device Edge, which pairs the RHEL operating system with MicroShift. MicroShift is a lightweight Kubernetes distribution built specifically to bring container orchestration to resource-constrained devices.

They both share the capabilities described earlier. Here's where they differentiate.

Red Hat Enterprise Linux

This is the smallest possible deployment with minimum system requirements of 1 core, 1.5 GiB RAM, and 10 GiB disk. Workloads can be RPM-based, virtual machines (KVM), or containerized (Podman). Basic workload orchestration is done using systemd, for example, starting up components in the right sequence.

Strengths:

• Smallest and lowest hardware requirements
• Easiest learning curve with no need to learn or understand Kubernetes
• Simple management of small numbers of static applications
• Capability to run any type of workload—packages (RPM), containers (Podman), or virtual machines (KVM)
• Transactional updates
• Easy access to special devices within the hardware ecosystem
• Well-suited for air-gapped or offline scenarios

When to use:

• For static workloads with 1 to 5 components and updates that can tolerate workload interruption. You can perform automatic container updates with Podman, but there will be a brief interruption when the old pod is stopped and the new pod is started. This takes longer for virtual-machine-based components.

Trade-offs:

• No built-in high availability (HA) or scalability. HA can be achieved using well-known RHEL technologies Corosync and Pacemaker (additional subscription needed). Alternatively, HA can be implemented at the workload level through active/passive database operations, memory-to-memory state replication, or similar methods.
• No complex container orchestration (such as dynamic adding of components, rolling updates, pod scaling, or workload isolation).

Example use cases:

• Transportation: Passenger information systems in rail cars
• Industrial: Software-defined control systems
• Commerce: Digital signage that might change regularly—with or without refreshed data

Management:

• Red Hat Edge Manager (preferred)
• Red Hat Ansible Automation Platform

Red Hat Device Edge with MicroShift

What's the difference between RHEL and Red Hat Device Edge? Technically, they're the same. Red Hat Device Edge additionally grants access and support to MicroShift, a lightweight Kubernetes distribution derived from OpenShift. Through this single platform, users choose the capabilities required for their environment—they can deploy the operating system starting with containerized (Podman) or virtualized (KVM) workloads.

Optionally, either at initial deployment or later, users can add Kubernetes orchestration by augmenting Red Hat Device Edge with MicroShift. The minimum system requirements are 2 cores, 2 GB of RAM, and 10 GB of disk. It supports the full Kubernetes API, without additional features provided by OpenShift such as developer tooling.

MicroShift provides workload portability. Applications developed for OpenShift or standard Kubernetes can run on MicroShift using the same manifests and tooling. To accomplish this, MicroShift was built from the ground up, incorporating only the core components required for container execution—such as etcd, container networking, and storage. This results in a different experience compared to OpenShift.

Also, it's worth mentioning MicroShift, in contrast to OpenShift, doesn't actively manage the underlying OS and isn't tightly coupled with it. While this provides greater flexibility for bespoke applications, it adds responsibilities for the solution builder to manage the operating system.

MicroShift has been improved in recent years with additional capabilities:

• Operator Lifecycle Manager (since 4.15)—standard OpenShift Container Platform catalogs aren't included
• Multus Container Network Interface (CNI) for multi-network pods (since 4.16)
• Low-latency workload and real-time kernel (since 4.16)
• Auto-recovery from backups (since 4.18)
• Gateway API (developer preview, since 4.18)

Strengths:

• Extremely small Kubernetes distribution—fits on hardware as modest as 2 cores and 2 GB RAM
• Quick to install and start—operational in minutes, not hours
• Full Kubernetes API on a single node—deploy cloud-born apps at the edge without re-architecting
• Derived from the OpenShift code base

When to use:

• When a modern microservices-based solution born in cloud environments needs to be scaled down to a small-form-factor, field-deployed edge device using management capabilities (Kubernetes API such as Helm)
• Container workloads that require edge locations within minimal size requirements
• Microservices-based solutions (rule of thumb: more than a handful of containers)
• When the organization is familiar with Kubernetes and able to develop for and operate it
• Dynamic workloads for when users frequently add components or applications
• Rolling updates of workloads, for example, allowing updates outside shop business hours to avoid interruption
• When full control of the underlying OS is needed

Trade-offs:

• No built-in high availability or scalability—needs to be implemented at the workload level; for example, via active/passive database operations, memory-to-memory state replication, or similar methods
• Added complexity of Kubernetes

Example use cases:

• Industrial: Internet of Things (IoT) gateway and condition monitoring
• Retail: Point of sale (POS) and point of information systems and loss prevention using machine vision
• Public sector and defense: Quickly changing workload profiles during or between missions of forward-deployed units, such as using different machine learning algorithms or models

Management:

• Red Hat Edge Manager (preferred)
• Red Hat Ansible Automation Platform
• Red Hat Advanced Cluster Management

Podman vs. Kubernetes: When (and when not) to use container orchestration

MicroShift adds Kubernetes container orchestration capabilities to Red Hat Device Edge. The central question for edge architects is whether Kubernetes is actually necessary for a given deployment.

Evaluating this decision depends on specific architectural triggers, hardware limits, and operational readiness:

What's the architecture of your solution? With a monolithic application made up of only a couple of containers, Podman with systemd orchestration is probably good enough. Rule of thumb: if only a handful of containers are required, Podman is likely the better choice. For microservices or event-driven architectures with more than 10 microservices in containers, Kubernetes is usually the right choice.

What type of container scheduling do you need? Keep in mind, Kubernetes was created to schedule a large number of containers across many nodes—if you have only 3 containers running on a single node, you probably don't need Kubernetes.

Do your workloads require high availability and automated recovery? Applications that need automated restarts, traffic-based scaling, and self-healing require Kubernetes container orchestration.

How mature is your development organization with containers and Kubernetes? If you've recently started the journey, try to avoid the additional complexity of Kubernetes—you can step up your game plan later. Also, do you really need a microservices architecture? You trade development complexity (less) for higher runtime complexity (more). Running 2 or 3 monolithic containers with a 3-week release-to-production cycle might be a better approach. Moving from RPM to containers might be the first step you need to take. You'd benefit from better isolation and decoupling of dependencies. For example, 2 different containers can easily use 2 different versions of Java or Python, independent of the host OS.

How mature are the containers you receive from your software vendor partners? Sometimes independent software vendors (ISVs) package old stuff in containers for the sake of it. But they still lack basic security, performance, and usability features. Not all containers have the same quality and maturity. There's a learning curve for both developers (who in this case likely sit outside a customer's organization) and the people responsible for operating the solution.

Do you need to scale from small to intermediate to large solutions? Will you run the same containers at the edge and in the core? Then Kubernetes is a must-have, because that's the standard API for declarative deployments in all scenarios.

How dynamic is your workload? Do you want to add or let your customers add components that rely on base services during the solution lifecycle? That's an indicator to use Kubernetes.

How frequently do you update your workload, for example, for new features or functionality? Do you or can you perform a rolling update without interruption (the workload must support this)? If you want to do it cloud-style with a highly dynamic once-a-week to maximum 3-month deployment cadence, Kubernetes with rolling updates is a must-have.

How frequently do you update the base system, such as OS security patches? If you need to update infrequently, such as for monthly patches or quarterly image or container updates, RHEL with Podman as the foundation of Red Hat Device Edge supports long-term stability. You should always apply security patches regularly. Don't rely on the assumption that your network is secure.

Conclusion

Thanks for staying with me. This part covered Red Hat Device Edge in detail—the edge solution targeting far-edge, small-form-factor deployments. Full control for tailor-made solutions, with optional Kubernetes container orchestration when you need it.

In the next part, we'll examine OpenShift topologies—from single node to compact clusters and the new 2-node architectures.

Ready to build? Review the Red Hat Device Edge product page or start a 60-day trial.