Unlock the power of edge computing with Red Hat's tailored solution for resource-constrained environments
Edge computing presents unique challenges that demand strategic technology decisions. With Red Hat's expanding portfolio of edge solutions, organizations often find themselves weighing multiple options: deploy standard Red Hat Enterprise Linux (RHEL), opt for Red Hat Device Edge, or implement Red Hat OpenShift at the edge? Whether you're planning your first edge deployment or optimizing an existing infrastructure, we’ll help you evaluate where Red Hat Device Edge fits into your strategy.
This is a big topic, so we’re breaking it into 2 parts:
- Part 1 (this post): A decision framework to help you figure out when Red Hat Device Edge makes sense, how it stacks up against RHEL and Red Hat OpenShift, and where MicroShift fits in edge environments.
- Part 2: An in-depth look into management strategies for Red Hat Device Edge—from package-based vs. image-based deployments to automation tools and how Red Hat Edge Manager is changing the game.
At the end of this series, you’ll have a clear framework for making informed decisions about Red Hat Device Edge adoption and feel prepared to effectively manage it.
What makes Red Hat Device Edge special?
Red Hat Device Edge might sound like a completely new product, but here's the interesting part: it's actually RHEL with a twist. Red Hat Device Edge binaries are identical to RHEL, but Red Hat Device Edge adds subscription-level differences and support entitlements. In other words, there's no technical difference between Red Hat Device Edge and RHEL; the magic lies in the subscription packaging and pricing strategy designed specifically for edge computing scenarios.
Note: Edge refers to computing environments where a large number of low-power, cost-sensitive devices are deployed across distributed and sometimes disconnected locations, requiring centralized lifecycle management and secure, consistent operations over time. Because edge scenarios vary widely, it is always recommended to speak with the Red Hat team to validate that a specific use case truly qualifies as “edge” under Red Hat’s definition and subscription terms.
Red Hat Device Edge is a bundle subscription that offers RHEL at a reduced cost, including Red Hat Satellite and potentially bundled with a Red Hat Ansible Automation Platform managed node subscription. But there is more! The Red Hat Device Edge subscription model enables the optional deployment of Red Hat's build of MicroShift.
MicroShift is a lightweight, single-node Kubernetes distribution co-developed with and derived from OpenShift that allows you to deploy on top of Red Hat Device Edge, making it possible to deploy traditional packaged and containerized applications along with virtual machines (VMs), as well as workloads using the Kubernetes API. It's specifically designed for resource-constrained environments and is officially supported by Red Hat, when deployed on top of Red Hat Device Edge.
Note: MicroShift isn't just a "reduced version" of OpenShift. It's optimized for minimal footprint and intentionally doesn't include the full set of OpenShift features.
Why edge computing needs different pricing models
Although Red Hat Device Edge and RHEL are technically identical platforms, Red Hat Device Edge exists to solve a distinct business challenge. The economics of edge computing environments are typically characterized by:
- Large-scale deployments of low-power devices
- Cost-sensitive hardware operating at the edge
- High scale, low-cost-per-device deployment models
In certain scenarios, standard RHEL subscription models aren’t cost-effective. Red Hat Device Edge provides a tailored offering with differentiated pricing and usage restrictions specifically aligned with edge computing needs.
By offering a lower-cost option, Red Hat Device Edge supports scalable deployments on low-footprint single socket devices, a contrast to high-resource servers running in cloud or datacenter environments.
MicroShift support: The edge computing advantage
Beyond differentiated pricing, a key distinction between Red Hat Device Edge and standard RHEL is exclusive MicroShift support. Red Hat exclusively supports MicroShift with Red Hat Device Edge subscriptions. MicroShift is optimized for single-node, resource-constrained environments and lacks multi-node high availability (HA), making it unsuitable for traditional datacenter or cloud deployments.
By limiting MicroShift support to Red Hat Device Edge, Red Hat ensures the platform is used in scenarios that match its technical design: scalable, low footprint edge deployments.
Understanding MicroShift's feature set
MicroShift achieves its small resource footprint through intentional feature limitations compared to OpenShift:
| Feature | In MicroShift | Role | Impact |
| Multi-node | Excluded | Kubernetes with more than one node | Single-node only. Limited HA can be achieved with two individual clusters with keepalived for failover. |
| Upstream Kubernetes API | Included | Core workload orchestration and API | Ensures compatibility with upstream Kubernetes. MicroShift is CNCF certified. |
| OpenShift API | Partial | Minimal OpenShift integration | Most OpenShift APIs are removed to reduce footprint. |
| Infrastructure services | Included | Routing, DNS, cert management | Essential for application networking. |
| Cluster operators | Excluded | Operating system (OS) configuration, lifecycle, upgrades | Reduces overhead but removes OS automation. |
| Web console | Excluded | User interface for cluster management | Reduces resources but requires automated management. |
| Monitoring stack | OpenTelemetry | Observability and metrics collection | Only basic telemetry available. |
| Registry services | Excluded | Internal image storage | Requires external registry integration. |
| Openshift Virtualization | Excluded | Virtual machine hosting | Use RHEL and KVM for virtualization. |
| Operator lifecycle manager | Optional | Operator maintenance | Not included by default, but can be installed on 4.15 and above. |
| Storage (LVM storage operator) | Included | CSI-based persistent storage | Comparable to single-node OpenShift storage. |
API support limitations
- MicroShift does support Kubernetes upstream APIs but does not support all the OpenShift APIs (those with "openshift.io" in apiVersion). It only supports SecurityContextConstraints and Routes.
- MicroShift does not include all the OpenShift infrastructure services, only openshift-ingress, openshift-dns, and service-ca.
Excluded components for resource optimization
- Cluster operators: Deliberately excludes OpenShift cluster operators (Cluster Version Operator (CVO), Machine Config Operator (MCO), etc.), which significantly reduces resource consumption but eliminates high-level OS configuration abstractions.
- Convenience components: Removes web console, monitoring stack, and registry services to conserve resources.
- Virtualization: Red Hat OpenShift Virtualization is unavailable. VM requirements must use standard RHEL virtualization based on KVM.
What's still available?
- Operator support: Edge application operators work well unless they require cluster operator dependencies. The AMQ Broker Operator represents successful MicroShift integration.
- Operator Lifecycle Manager (OLM): Not included by default but can be optionally added since version 4.15.
- Monitoring: While no full monitoring stack is included out of the box, the observability component supports data collection using OpenTelemetry, the same powerful framework used in Red Hat OpenShift.
- Storage: Includes the logical volume manager storage (LVMS) Container Storage Interface (CSI) provider, comparable to single-node OpenShift storage capabilities.
Choosing the solution: Red Hat Device Edge vs. Red Hat alternatives
Red Hat Device Edge vs. RHEL
Red Hat Device Edge is the preferred choice for suitable edge deployment scenarios using single-socket devices given its tailored pricing model.
Red Hat Device Edge with MicroShift vs. Red Hat OpenShift
When you need containerized services at the edge using Kubernetes APIs, the decision between Red Hat Device Edge with MicroShift and Red Hat OpenShift (single-node or three-node clusters) comes down to 4 critical factors:
1. Application architecture requirements
Choose Red Hat Device Edge when your solution is using traditional RPM applications and you need to operate alongside containerized workloads on the same system.
2. Kubernetes implementation scope
Choose Red Hat Device Edge with MicroShift installed when:
- MicroShift’s feature set is enough.
- Kubernetes is a supporting element in your architecture, not a primary focus.
- Your team has limited Kubernetes expertise.
- No medium-term plans exist for platform expansion.
- You want to minimize the learning curve.
3. HA requirements
If your solution does not require HA, Red Hat Device Edge is the appropriate choice because MicroShift doesn't support additional worker nodes.
4. Hardware resource constraints
Choose Red Hat Device Edge when hardware resources are insufficient for OpenShift requirements.
Alt text: Minimum platform resource requirements comparison
* You would need to add additional memory (+1.5 GiB) for HTTP(S) and FTP network installation.
5. Organization profile
Edge computing adoption typically involves 2 organizational profiles:
- Cloud-native organizations looking to extend existing cloud services to edge environments who generally require advanced Kubernetes capabilities
- Device-focused organizations modernizing existing local infrastructure who typically prefer resource-constrained solutions and may not require Kubernetes deployment capabilities
The first group typically seeks the advanced capabilities offered by OpenShift. Device-focused organizations, however, prefer Red Hat Device Edge because it aligns better with their existing expertise, operational workflows, and expected device hardware footprint and cost.
What’s next
This article focused on determining when Red Hat Device Edge is the right choice, comparing it to standard RHEL and OpenShift, and understanding the unique role of MicroShift in enabling Kubernetes at the edge. By now, you should have a clear framework for selecting Red Hat Device Edge in scenarios where resource constraints, cost considerations, and Kubernetes-lite capabilities align with your organizational needs.
The key takeaway is understanding where Red Hat Device Edge fits best:
- Resource constraints → Red Hat Device Edge
- Kubernetes HA requirements → OpenShift
- Hybrid traditional + containerized workloads → Red Hat Device Edge
- Rich Kubernetes feature set needs → OpenShift
Choosing Red Hat Device Edge is only the beginning. Once you’ve decided to use Red Hat Device Edge, the next critical question is: how do you manage it at scale?
In the next blog post, we’ll dive into Red Hat Device Edge system management. We’ll cover the differences between package-based and image-based deployments, the role of tools like Red Hat Satellite, Red Hat Ansible Automation Platform, and Red Hat Advanced Cluster Management for Kubernetes, and how Red Hat Edge Manager will shape the future of image-based edge operations. You’ll also see how MicroShift introduces new considerations for application lifecycle management alongside traditional OS management.
关于作者
Hey there! I'm Luis, a tech enthusiast who thrives at the intersection of Edge Computing, AI/ML, and MLOps. With over 15 years in the industry, I’ve built a career around solving complex problems, driving innovation, and pushing the boundaries of open-source technology.
By day, I help organizations design scalable architectures and refine their cloud-to-edge strategies, with a strong focus on extending AI solutions to the Edge for real-time processing, automation, and efficiency. By night, I geek out over the latest AI models and MLOps tools.