Skip to main content

A Shared Vision For Edge Computing

The Eclipse Foundation is a member-driven, vendor-neutral organization. I cannot count the number of times I have said this since I started at the Foundation in February of 2019. As a Foundation staffer, my job is to serve the community and assist its members in driving their initiatives. During the past 12 months or so, I have had the privilege to work closely with our Edge Native Working Group on what I consider to be a very special initiative.

After its creation in December 2019, one of the main goals of the Edge Native Working Group has been to define its vision for Edge Computing and share it with the rest of the industry. The community decided at that time to write a comprehensive white paper to accomplish this goal. At first, I simply supported that effort, but ended up writing part of it.

Today marks the launch of our white paper, titled “From DevOps to EdgeOps: A Vision for Edge Computing”. And I am proud to say that my vision for Edge Computing is, in fact, a vision shared by the Edge Native Working Group.

So, what will you find in it? A comprehensive analysis of the market, a clear definition of what Edge Computing is and our vision for its future. Here is our argument:

  1. The challenges of Edge Computing are distinct from those of Cloud Computing. Using Cloud approaches, tools and platforms at the Edge without modifications to meet these edge challenges will simply not work.

  2. Industry experts differ on their opinions about whether there is a single “Edge” or many Edges. Our perspective is that there are so many edges that the space from the very end of the Edge and all the way to the Cloud can be seen as a continuum. This means that a proper edge platform will need to be able to position the various mix of devices and components at any physical location found in this continuum.

  3. Edge Computing is about bringing computing power and storage as physically close to the source of the data as possible. This means edge computing nodes have to face many constraints that are not typically found in the Cloud, such as limits to power consumption, unreliable networks and many others.

  4. DevOps tools and techniques transformed the way we build and deliver software. However, DevOps was born in the Cloud. Since Edge environments are radically different, there is a need to adopt a new paradigm -- DevOps for the Edge. This is EdgeOps: our vision for the present and future of Edge Computing.
What makes this white paper special is that it's been written by actual, experienced practitioners of Edge Computing. Working on it with the other authors has been a real pleasure. Many thanks to Robert Andres (Eurotech). Luca Cominardi (ADLINK Technology) and Kilton Hopkins (Edgeworx) for their dedication in bringing this white paper to light.

You can download the white paper here.


Popular posts from this blog

Eclipse Amlen v1.0: A Milestone in the Growth of MQTT

Over ten years ago, the Eclipse Foundation launched the Eclipse IoT working group . MQTT was one of the pillars of that launch. The first three projects were Eclipse Paho , a collection of MQTT clients, Eclipse Mosquitto , an MQTT broker, and Eclipse Kura , a Java/OSGi solution for IoT gateways that supports the protocol. To say that MQTT is in our genes would be an understatement. Since then, usage of MQTT has grown significantly. Year after year, the simple yet powerful publish/subscribe protocol is the most widely used IoT-specific protocol in our annual developer surveys . For example, in the 2021 edition, 44% of respondents stated they are using it. We like to think we are at least partly responsible for that. By the way, our 2022 survey is currently underway; you have until June 15, 2022, to participate. Click here to share your insights after finishing this post, of course. IBM has been a key player in our MQTT ecosystem for a long time. In 2021, the company brought its commit

Eclipse IDE for Embedded Developers Now Runs on the Raspberry Pi!

The Eclipse IDE is the project that started it all for the Eclipse Foundation . From the beginning, Eclipse IDE was meant to run on multiple platforms; it now supports Linux, Mac OS and Microsoft Windows. Since it is written in Java, it also supports multiple processor architectures. However, support for 32-bit architectures has been dropped in version 2018-12. This meant recent versions of the IDE would not run on the Raspberry Pi anymore. The introduction of the Raspberry Pi 4 in June 2019 gave hope to Eclipse on Pi fans. With its 64-bit quad core ARM Cortex-A72, the Pi 4 was a good hardware platform to work with. It became even more attractive in May 2020, with the introduction of the 8Gb variant. The Eclipse community took notice of those developments. Version 2020-09 of Eclipse IDE now ships with experimental support for 64-bit ARM (aarch64) on Linux.  Those developments mean embedded and IoT developers can now work on the Raspberry Pi 4 by installing the plugins provided by the 

Sparkplug: From Specification to Standard

This week, the Eclipse Foundation announced that the Sparkpug® 3.0 specification has been published as an International Standard. That sounds impressive. But what does it mean, exactly? And how will this impact the evolution of Sparkplug? To answer this question, let’s take a step back and consider what standards are. The technology industry loves standards. For example, USB is a set of standards managed by the USB Implementers Forum, Inc. (USB-IF), a non-profit corporation founded by the companies that developed the USB specification. The Eclipse Foundation describes Jakarta EE as a standard: a set of  specifications for enterprise Java application development. In the IoT and Industrial Automation world, OASIS Open also presents the MQTT protocol as a standard. However, standards play a much more pervasive role in society. There are standards for building homes and others that define how cars should work. Standards permeate our lives. To understand the significance of this week