Eclipse ioFog 2.0: The Next Generation

Later this quarter, the Eclipse ioFog team will release version 2.0 of the platform. To understand the value of the new features in the release, it is important to first understand some of the key concepts in ioFog.

The Edge Compute Network (ECN) is the central pillar of ioFog. The ECN is comprised of edge devices that operate outside the data center, at the edge of the enterprise network, performing compute, storage, and networking services locally. The ECN provides resilience, fault tolerance, security, and low-latency connections between edge devices which, in turn, deliver the scalability necessary for large-scale edge computing deployments.

The core component of each ECN is the Controller.  It orchestratesItorchestrates the tasks of all other components. The Controller is supported by instances of the ioFog Agent, which report directly to it. Agents are responsible for infrastructure tasks such as running edge microservices, mounting volumes, and managing resources.

The most important change in this release of ioFog is the replacement of the ioFog Connector with a trio composed of the:

  • ioFog Router
  • ioFog Proxy
  • ioFog Port Manager

This overhaul of the ECN adds tremendous flexibility to ioFog and illustrates how open source is a catalyst for innovation.

ioFog Router

The ioFog Router is based on Apache Qpid. It enables microservices to communicate with each other and tunnels traffic on public ports to these microservices. By default, each Controller and Agent run their own instance of the Router.

Although the Controller and Agents communicate over HTTP, Router instances rely on the Advanced Message Queuing Protocol (AMQP). AMQP, an OASIS standard, was designed with security, reliability and interoperability in mind.

ioFog Proxy

The Proxy microservice is an internal component on the ECN. Its purpose is to translate HTTP requests to AMQP where necessary. When exposing a microservice, instances of the Proxy are deployed and linked to the router instances involved.

The ioFog Proxy is based on project Skupper from Red Hat. Skupper is a Layer 7 service interconnect. Its main use case is to enable secure communications across Kubernetes clusters with no virtual private networks (VPNs) or special firewall rules. Because ioFog leverages Skupper, ECNs can span multiple cloud providers, data centers, and regions.

Figure 1 illustrates the relationship between the core components of the ECN in ioFog 2.0.

Figure 1: ioFog 2.0 Core Components

ioFog Port Manager

The ioFog Port Manager is only required when the platform is integrated into a Kubernetes cluster. The Port Manager is responsible for deploying proxies on the Kubernetes cluster as needed when exposing microservices on external public ports.

Additional Improvements in ioFog 2.0

In addition to the overhaul of the ECN, the specification of the Controller to Agent API has been stabilized in ioFog 2.0. This means ioFog community members can now create custom implementations of the ioFog Agent to fit specific use cases. For example, they can write an Android-native agent to drive microservices on a mobile device.

Several smaller features have also been added to the ioFog Engine, including:

  • Better Docker image pruning
  • Registry management
  • Better centralized logging support

ioFog 2.0 Is Just the Beginning

The roadmap for the ioFog 2.x series of releases is equally impressive.

The ioFog team intends to further improve the ioFog ECN by adding support for peering optimization, cost mechanisms, and dynamic routing, among others.

The team will also implement a new container tagging format that provides detailed descriptions of the edge nodes’ hardware capabilities, including the CPU architecture, type of onboard GPUs, and the presence of onboard hardware accelerators. This capability will be augmented by a new build system that will automatically produce optimized versions of the containers hosting the microservices for all relevant hardware permutations.

With these kinds of features in ioFog, the Eclipse Edge Native Working Group will be one step closer to fulfilling its vision for edge devops — edgeops. The goal of edgeops is to enable people to use their existing skills and devops tools, write in their preferred languages, reuse their existing data center and cloud applications, and make it all work seamlessly with the edge.

Get Involved in ioFog

To connect with other ioFog enthusiasts and learn more about the platform, visit our community page.

About the Author

Frédéric Desbiens

Frédéric Desbiens