Written by Jim White, Co-Chair of the EdgeX Foundry Technical Steering Committee and CTO of IOTech
Every six months, the EdgeX Foundry technical community gets together to review its recent release (collecting lessons learned, assembling release notes, etc.) and to plan out its next release. For the last three years, these meetings have been face-to-face events held in venues across the globe. It has become an event which many in the community have come to enjoy as it allows us to celebrate our success, plan out the next release, and at the same time reconnect with people that have become close professional friends.
Alas, the global pandemic claimed another causality – albeit a far less important one in relation to world events – when we had to cancel our face-to-face meeting this spring. We held a virtual event instead and, though different, it was still fun and successful – thanks to the incredible efforts of the development community that has been the life blood of the project since the project’s inception. We had more than 35 members attending the online sessions each day and managed to get everything accomplished that we planned and even had time for a mini-educational conference (called the “Unconference”) that allowed community members to highlight new EdgeX-based solutions and new project ideas.
The Geneva Release
Our planning meeting is always at the tail end of our current release efforts. We have an EdgeX development “freeze” period, which means no more feature coding can be done as we clean up bugs and tackle documentation.
Codenamed “Geneva” – this is is EdgeX Foundry’s sixth release but the first for 2020. The highlights of the Geneva release include:
- Dynamic or automatic device on-boarding – for protocols where it makes sense, this allows EdgeX to automatically provision new sensors and have the sensor data start to flow through EdgeX
- Alternate messaging support – where applicable, allows adopters to use any messaging implementation under the covers of EdgeX to include MQTT, 0MQ, or Redis Streams.
- Better type information is associated to sensor data – allowing analytics packages and other users of EdgeX sensor data to more easily digest the data and aid in transformations on the data
- REST device service
- Batch and send export – allowing sensor data to be sent to cloud, on-prem or enterprise systems at designated times
- Support for MQTTS and HTTPS export
- Redis as the default DB – deprecating MongoDB for license, footprint/performance, and ARM support reasons
- Adding the Kuiper rules engine – a new rules engine that is smaller and faster and written in Go which replaces EdgeX’s last Java micro service.
- Improved Security
- Interoperability testing
- Improved DevOps CI/CD – now using Jenkins Pipelines to produce EdgeX Foundry project artifacts
The Hanoi Release
As for our semi-annual planning meeting, we set up the scope of our next release which is codenamed “Hanoi.”
There are some significant notable features in this upcoming release which is scheduled to arrive in the October/November 2020 timeframe.
- Device service to application service message bus – allowing data to “stream” more directly (faster) through EdgeX without persistence.
- Improve support for running device services on different hosts
- Secure service to service communications – enabling EdgeX services to live on different hosts and communicate securely
- Data filters in the device service – allowing repetitive or meaningless sensor data to be discarded sooner in the collection process
- Performance guidance – giving adopters better understanding of hardware requirements and data flows which can help them architect edge solutions for their use case
- Improved interoperability testing
- Hardware Root of Trust abstraction – allowing EdgeX’s to get its secret store master key from hardware secure storage
EdgeX APIs and the EdgeX 2.0 Future
More importantly, this release will include work on a new API set for our microservices. We call this the V2 API set. As the name implies, it will be the EdgeX APIs that will be featured in version 2 of EdgeX in the near future (perhaps as soon as 2021). A portion of the V2 APIs will be available for exploration with the Hanoi release – allowing developers to experiment and test the new APIs.
During the Hanoi release, as we work on V2 API, we are making the APIs easier to use, decoupling data elements used in the message communication from the operations, and generally allowing for better security, better testing, use of different transport infrastructure, and easier extension of the APIs going forward. So, while Hanoi is expected to be a minor version, it provides the footing for a new major release (EdgeX 2.0) next year.
We invite you to have a look at the new EdgeX release – Geneva. Learn more here: https://www.edgexfoundry.org/release-1-2-geneva/. Here is hoping that the next six months bring health and safety back to all of our lives and that we’ll be able to reconvene the community of EdgeX Foundry experts soon.
