Eclipse ioFog Enhancing Deployment and Edge Resource Management

The latest version of Eclipse ioFog, Eclipse ioFog 3.0, is due to release in Q4. We’ve made several improvements to it to enhance its capabilities. 

The early days of edge computing were largely defined by experimentation: people were seeing what was possible. Since it has become more mainstream and better-defined, issues have emerged, particularly as larger scale rollouts of edge devices started happening. 

Solving those issues drove the two major themes for this latest version of ioFog: making global deployments easier and improving the management of edge resources. Along with that, we also added a few quality-of-life changes to the UI. 

 

Enhancing and Automating Configuration 

One of the major changes we made to make larger scale deployments easier are improvements to configuration, particularly the ability to automate configuration. 

Let’s take the example of time zones. If you’re launching a global deployment, then everywhere you put a device could be in a different time zone. Traditionally applications either pull their time zone from the environment they’re running in, or they’re configured ahead of time. If you configure ahead of time and want to roll out more than one device, you’re going to have to go back and change it every time. And if the applications pull from the environment they’re running in, they’re often going to be wrong. 

The latest version of ioFog will simply inject the time zone for you into the microservice from the edge compute node. This way you don’t need to track where particular devices are for later configuration. 

Granular Insights of Microservice Rollout 

We also added more detailed insights into microservices to streamline rollouts. Up until now, you’ve only been able to get very general information when a microservice is being pulled by an edge node. Essentially, you could tell if it was finished or not, but that was about it. 

We’ve added the ability to see a progress report with a percentage remotely on the ioFog controller. This makes it a lot easier to get useful insights that can help you improve a rollout. For example, if you are rolling out in five geographies and after half a day two of them are only at 15%, you can now see what is causing the slow down. Maybe the issue is that the two slow rollouts are on a network where you forgot to purchase overages, and the process is being throttled by your vendor. Before, you would’ve had no idea this was happening. Now, with more detailed insights, you can see the progress of the rollout and any issues that are creating a problem so you can adjust where necessary.

As part of that addition, we’ve also made a few augmentations to error handling to make it easier to figure out what’s gone wrong with a microservice.

Certificate Identification More Flexible and Inclusive

For a long time, Eclipse ioFog had the ability to generate certificates via community pull requests. But, based on feedback from users, we’ve realized we need to be more flexible and inclusive in how we do identity certificate verification. So, we added the ability to use system trust anchors as well, which makes ioFog better prepared to verify identities in different geographies. 

Custom Installation Plug-in

If you were planning on rolling out the ioFog agent onto, say, 1,000 devices to get them ready to go out, you might want to prepare your actual device. For example, you may want to add security keys or configuration files. 

To make this easier, we opened a custom installation plug-in for the ioFog agent, allowing you to script out how the agent gets installed and set up.

Installation Package Universal to Linux Distributions

There are a lot of customized versions of Linux out there, and some esoteric ones too. The latest version of ioFog will be universal to all Linux distributions. So, no matter what obscure version you’re running, it’ll work. 

Addition of Application Templates

We’ve also added the ability to preconfigure an entire ioFog application with templates. 

Previously, you’d set up your edge application, and it would be parsed by the controller and deployed. If other developers wanted to deploy an application of their own, they’d have to go through the whole YAML to make sure all the settings were correct for their geography. 

The addition of application templates means that users can build a template, instead of having to have these specific deployment YAML setups. With a template, you can leave a few parameters open and make the rest universal. This way, larger scale deployments get the flexibility they need, but you can also more easily control these deployments and ensure that everything is working properly. 

This also opens up the opportunity for third parties to develop what we call an Edge App Store. You can set up your app so that users will only need to put in the pieces they need to get the functionality they want. So, for third parties, an ioFog app template is actually close to sellable. 

This makes the addition of app templates good for individual users, as well as the ecosystem in general. Users get more functionality, and third parties looking to monetize ioFog can make ioFog application templates that are close to sellable.

EdgeResources: Improvements to Structure of Data Modeling

Every edge device has the same issue of heterogeneity. To handle it, we need a way to attach information about what that edge node has to the data model of that edge node. 

We added the opening for that to the next release of ioFog. You can define and attach all kinds of things to that edge node so that it exposes into the control plane, and then you can make ioFog controls and decisions based on those edge resources. 

A good example of this is an AI accelerator chip. If you’ve been using edge resources to map the presence of that chip for the edge node, that makes that edge node eligible for any microservice deployments that require that chip. 

EdgeResources is an open pattern, such that you can define what is in your Edge node however you like. And once you’ve done that, you can put those pieces together in a structured way. If you were managing, say, cameras, there’s no master list that your particular cameras have to be on. You just need to list and label them according to your own system and you can start deploying edge applications on them. 

Future of ioFog: Zero-Touch Provisioning

All these changes are part of the longer term trajectory for Eclipse ioFog. The granular control of EdgeResources, combined with the improvements to global deployments, set us up to begin merging the homogeneity and universality elements. And our changes to EdgeResources give resources a structure that makes them more open to automation.

With the changes we’ve made and the improvements we have planned for future releases, we’re really looking to enable automated handling of heterogeneity. The overall objective is to simplify complex data flow management, which is currently doable but with difficulty. The biggest thing we’re moving towards is automated, secure rollout: basically, as close as we can get to zero-touch provisioning. 

In fact, we’ve been watching the great progress happening with Eclipse zenoh, which is an amazing protocol. We’re currently planning an integration to enable ioFog to automatically install and deploy Eclipse zenoh for you. 

Get Involved

If you’re getting into ioFog for the first time, we really encourage you to check out the website at iofog.org. That’s the documentation site for the project, and it has everything you need to know. 

Beyond that, we want you to come talk to us. That can either be through the Edge Native Working Group or directly in the ioFog Slack.