[Update Aug. 9] —EdgeX Foundry’s “California” release of its EdgeX IoT middleware adds security features and is rewritten in Go for faster boot and a smaller footprint, enabling it to run on the Raspberry Pi and other small footprint computers.



The Linux Foundation’s EdgeX Foundry project announced its second major release of its EdgeX IoT middleware for edge computing. The “California” release adds security features including reverse proxy and secure credentials storage. It’s also rewritten in Go to offer a smaller footprint This makes it possible to run EdgeX on relatively constrained edge devices such as the Raspberry Pi 3.

EdgeX Foundry was announced in late July 2017, with a goal of developing a standardized, open source interoperability framework for Internet of Things edge computing. EdgeX Foundry is creating and certifying an ecosystem of interoperable, plug-and-play components to create an open source EdgeX stack that will mediate between multiple sensor network messaging protocols as well as cloud and analytics platforms.







EdgeX architecture

(click image to enlarge)



The framework facilitates interoperability code that spans edge analytics, security, system management, and services. It also eases the integration of pre-certified software for IoT gateways and smart edge devices.

“Our goal is to decouple connectivity standards and device interfaces from applications,” said Jason A. Shepherd, Dell Technologies IoT CTO and Chair of the EdgeX Foundry Governing Board, in an email interview with Linux.com. “EdgeX will enable flexibility and scalability through platform independence, loosely-coupled microservices, and the ability to bring together services written in different languages through common APIs. These cloud-native tenets are absolutely required at the edge to scale in an inherently fragmented, multi-edge and multi-cloud world.”

EdgeX is based on Dell’s seminal FUSE IoT middleware framework, with inputs from a similar AllJoyn-compliant project called IoTX. Dell is one of three Platinum members alongside Analog Devices, and Samsung. EdgeX Foundry now has 61 members overall, including AMD, Canonical, Cloud Foundry, Linaro, Mocana, NetFoundry, Opto 22, RFMicron, and VMware.\





Conceptual diagram for EdgeX (left) and tiered deployments on different types of gateways and fog servers

(click images to enlarge)



The California release follows the initial Barcelona release, which arrived last October. Barcelona provided reference Device Services supporting BACNet, Modbus, Bluetooth Low Energy (BLE), MQTT, SNMP, and Fischertechnik, as well as connectors to Azure IoT Suite and Google IoT Core.

The major new features in in EdgeX California aim to improve security. A new reverse proxy based on Kong helps protect REST API communications and secrets storage. The reverse proxy requires any external client of an EdgeX microservice to first authenticate itself before loading an EdgeX API.

The new secure storage facility for secrets is based on HashiCorp’s open source Vault. It lets you securely store sensitive data such as username/password credentials, certificates, and tokens within EdgeX for performing tasks such as encryption, making HTTPS calls to the enterprise, or securely connecting EdgeX to a cloud provider.

“Our Barcelona release had no security features because we wanted all the security layers to be defined by a community of industry experts such as RSA, Analog Devices, Thales, ForgeRock, and Mocana, rather than only from Dell,” said Shepherd. “The Reverse Proxy and Secrets Store is the foundation from which everything else is built.”



Shift to Go

The other major change in California was that the code was rebuilt from the original Java with the Go programming language. The process delayed the release by several months, but as a result, California has a significantly reduced footprint, startup time, memory, and CPU usage. It fits into 42MB — or 68MB with container – and can now boot in less than a second per service compared to about 35 seconds (see chart below).







Comparison of EdgeX Barcelona and California footprint and startup performance

(click image to enlarge)



Export services additions for “northbound” connectivity to the XMPP messaging standard, the ThingsBoard IoT platform for device management, data collection, processing, and visualization, and Samsung’s Brightics IoT IoT interoperability platform

Improved documentation, now available in Github

Full support for Arm 64

Blackbox tests for all micro services within build and continuous integration processes

Improved continuous integration to streamline developer contributions

Additional new features in the California release include:

According to Dell’s Shepherd, the switch to Go was not only about reducing footprint, but to avoid the need for vendors to pay a Java license fee for commercial deployments. In addition, Go has expanded EdgeX’s developer base.

“Go’s concurrency model is superior to most programming languages, has the support of Google, is used by Docker, Kubernetes and many other large software development efforts, and is growing broadly in IoT circles,” said Shepherd. “We doubled our community in the months after the January Go-Lang Preview. There is a learning curve associated with getting a typical object (Java, C++) developer to move to Go (a functional versus object language), but overall the move has been good for fostering more enthusiasm about the platform as well as improving it.”

— ADVERTISEMENT —



Shepherd noted that Go is only a baseline reference language. Developers can use the same APIs with other languages, and the project will support C in addition to Go for the Device Service SDKs. Because C can reduce the footprint even further than Go, it may be the better choice for applications built on a low-end “thin edge” gateway with a lot of Device Services, such as many different sensor protocols, said Shepherd. However, EdgeX Foundry chose Go because it is more platform independent in terms of hardware and OS.



Next up: Delhi and beyond

The upcoming Delhi release due in October will include components such as manageability services, Device Service SDKs, improved unit and performance testing, and a basic EdgeX UI for demos. It will also add more security features including improved security service bootstrapping of Kong and Vault.

According to Shepherd, other security enhancements planned for Delhi include “tying Kong and potentially other security services to an access control system providing access control lists for granting access to various services.” Future versions of EdgeX will also establish a Chain of Trust API for systems that don’t have something like TPM. “We want to build out an API that allows EdgeX to establish a root of trust with the platform it rides on,” said Shepherd.

Other plans call for automating security testing, including “building an entire security testing apparatus and look at pen-testing type of needs,” said Shepherd. The project will also enhance the Vault-based secure storage system. “Today, EdgeX microservices get their configuration and secrets from the Consul configuration/registry service, but the secrets, such as passwords for database connections, are not secure. We want application secrets to come from Vault. Vault and Consul are provided by HashiCorp and we think there is a good way to use the two together.”

Looking forward to future releases, EdgeX plans to reduce the footprint even more to run in 128MB or lower. There are also roadmap items for “more integration to edge analytics, rules engines, and CEPs,” said Shepherd. “We are currently working with NodeRed as an example.”

When asked about the potential for integrating with other cloud-driven IoT platforms such as AWS Greengrass or Google’s new Cloud IoT Edge platform, Shepherd had this to say:

“Our ability to work with some of the proprietary cloud stacks depends on their openness and architecture, but we are certainly exploring the opportunities. The whole point is that a developer or end user can use their choice of edge analytics and backend services without having to reinvent the foundational elements for data ingestion, security and manageability.”

Separately, Shepherd noted: “Our completely open APIs — managed by the vendor-neutral Technical Steering Committee (TSC) to ensure stability and transparency — decouple developers’ choice of standards and application/cloud services to prevent them from being locked in via one particular provider’s proprietary APIs when the data meter starts spinning.”

This article is copyright © 2018 Linux.com and was originally published here. It has been reproduced by this site with the permission of its owner. Please visit Linux.com for up-to-date news and articles about Linux and open source.

