Q&A: EdgeOps Technologies at the Eclipse Foundation

While most developers are familiar with the benefits of cloud-based DevOps, the requirements and environments for edge computing are very different. For example:

• Edge computing environments are heterogenous rather than homogenous.
• The edge is not as elastic as the cloud.
• At the edge, compute and power resources are limited, and network connections are slower and less predictable.

The bottom line is that traditional DevOps technologies and tools are not well-suited to edge computing. This has led to the emergence of what we refer to as “EdgeOps.”

EdgeOps technologies and tools are built from the ground up to support emerging edge computing applications. While still an emerging market, some EdgeOps-friendly tools and technologies are available today. A large percentage of them are open source, and a significant number are hosted at the Eclipse Foundation.

To help developers understand more about EdgeOps, its role in edge computing, and the technologies available today, I asked Frédéric Desbiens, the IoT and edge computing program manager at the Eclipse Foundation, for additional insight.

Q. How do you describe the need for EdgeOps to developers?

A. When you take a closer look at the unique challenges, characteristics, and deployment considerations in edge computing, it’s clear that purpose-built technologies are needed.

I like to refer to this illustration to summarize the differences between EdgeOps and DevOps principles (Figure 1).

Figure 1: EdgeOps Challenges and Requirements Compared to DevOps

The challenges are important because they’re very specific to the edge, and they can have quite serious consequences if not properly addressed.

You choose edge computing to minimize latency and data processing. If you’re operating an oil and gas refinery, you don’t want to wait for remote field data to be sent to the cloud, processed, and sent back before making a decision. But, bandwidth from remote nodes is often an issue and cellular communications are very expensive. Resiliency is also hugely important. Think about an autonomous vehicle that suddenly can’t communicate with the connected objects it uses for guidance. And issues with data sovereignty can result in healthcare or personal data being shared outside of a hospital, province, state, or country.

In terms of characteristics, edge computing solutions have longer lifespans than most IT projects. If you add edge computing on every floor of a smart building, you want it to be viable for many years, if not decades. Edge solutions must support a wide variety of devices with different processors, capacities, and power requirements. And those devices must be rugged enough to resist dust, water, and other environmental contaminants.

From a deployment perspective, edge computing applications also have unique requirements. For example, updates must be made in a very careful way and take into account the physical and connectivity limitations of the edge devices. In some cases, you may have to send a technician to the field, though eliminating this need is key to efficient EdgeOps. This is quite different from the convenience of the cloud.

Even in cases where cloud approaches such as microservices are used, technologies must be fully adapted for the edge. Microservices in edge computing environments must be more robust than those in cloud environments because edge environments are less predictable and resilient than cloud environments.

Full-featured EdgeOps platforms deliver on all of these requirements, whereas DevOps platforms were designed to meet different requirements.

Q. Why should developers take an open source approach to EdgeOps?

A. There’s so much diversity and richness available in open source EdgeOps technologies today that you really don’t need a commercial platform. With open source, all the technologies you need are available, and you can choose the deployment model that’s best for your use case, instead of trying to understand complex licensing schemes for commercial services or locking yourself into a specific cloud or software provider. You have more control and more flexibility than with proprietary EdgeOps software. And of course, it’s nice that open source software is free.

Q. Which Eclipse Foundation projects and communities are relevant to EdgeOps?

A. The Eclipse Foundation hosts a large number of projects and communities that give developers the features and flexibility needed for a comprehensive edge strategy. Projects are not proofs of concept or blueprints. Tested and proven code is available and ready for use. Some projects, such as Eclipse fog05 and Eclipse ioFog, are already used in edge production environments.

Core edge projects include:

• Eclipse fog05, a decentralized edge platform that uses a unified compute fabric to tie together constrained devices, edge nodes, and cloud resources.
• Eclipse ioFog, a centralized edge platform that provides resilience, fault tolerance, security, and low-latency connections between edge devices in an edge compute network.
• Eclipse zenoh, a publish/subscribe protocol designed to unify data in motion, data in use, data at rest, and computations.

Other complementary projects include:

• Eclipse Cyclone DDS, an implementation of the Data Distribution Service (DDS) protocol frequently used in robots, autonomous vehicles, and other demanding applications.
• Eclipse Ditto, a highly flexible digital twin platform.
• Eclipse Hara, a client implementation of the Eclipse hawkBit API.
• Eclipse hawkBit™, a platform to deploy software updates to constrained devices and edge nodes.
• Eclipse Hono™, a scalable message routing platform that supports protocols such as MQTT, CoAP, and AMQP.
• Jakarta® EE, a set of specifications that define a platform for Cloud Native Java applications.
• Eclipse JKube™, a collection of plugins and libraries for building container images of Java applications.
• Eclipse Kapua™, a modular IoT cloud platform to manage and integrate devices and their data.
• Eclipse Kura™, an extensible IoT edge framework that’s based on Java/OSGi and offers API access to the hardware interfaces of IoT gateways.
• MicroProfile™, a baseline platform definition that optimizes enterprise Java for a microservices architecture.
• Eclipse Mosquitto™, a message broker that implements the MQTT protocol.
• Eclipse Paho, client implementations of the MQTT and MQTT-SN protocols.
• Skupper, a Layer 7 service network interconnect that enables secure communications across edge nodes with no virtual private networks (VPNs) or special firewall rules. Skupper is not an Eclipse Foundation project, but has been integrated into Eclipse ioFog v2.0.

Projects span multiple communities, including the Eclipse Edge Native Working Group, Eclipse IoT, OSGi Working Group, and Sparkplug Working Group, so there are many people contributing from different perspectives. This is important for a well-rounded edge strategy.

Q. How do Eclipse Foundation projects fit within the broader EdgeOps ecosystem?

A. When you look at technologies for development and operations across the edge-to-cloud continuum, you can see where Eclipse Foundation projects fit in relation to other technologies. We like to use this matrix to illustrate the role the Eclipse Foundation plays in developing this emerging market (Figure 2). The color logos are Eclipse Foundation projects.

Figure 2: Key Open Source Projects in the EdgeOps Matrix

The Eclipse Foundation ecosystem is strong. We also work closely with other open source communities, including the Cloud Native Computing Foundation. We gladly work with other open ecosystems because the debates, ideas, and collaboration ultimately result in better technologies for EdgeOps.

Learn More

To learn more about EdgeOps and the edge technologies being developed at the Eclipse Foundation:

• Visit the Edge Native Working Group website.
• Check out the many projects listed above.
• Watch for our soon to be released white paper EdgeOps: A Vision for Edge Computing.