Written by Jim White, Chair of the EdgeX Foundry Technical Steering Committee and CTO of IOTech Systems
It’s the holiday season upon us in the US. On behalf of the EdgeX Foundry community, I’d like to wish you and yours a very warm, blessed and peaceful holiday season.
This time of year is special to me because it usually means some peace after a some long hard release cycle. The EdgeX community is working on EdgeX 1.3 – the Hanoi Release. It is a minor (dot) release and backward compatible with Edinburgh (1.0), Fuji (1.1) and Geneva (1.2) along with any patch release of these. For more details on the Hanoi release, stay tuned for my release blog in a few weeks.
Virtual Face-to-Face
In addition to the release, we also completed our semi-annual release planning sessions this past week in order to get ready for our next release for the spring of 2021. The next EdgeX Foundry release is called Ireland.
Up until this year, the planning meetings were held in-person at a venue hosted by one of our sponsoring companies. We called the events our “face-to-face” meetings because it was the only time that the contributors and members of our global development community had a chance to meet in person. This year, due to the pandemic, our planning sessions have had to be held “virtually.” Somewhat paradoxically, this had led members of the community to refer to these on-line meetings now as “virtual face-to-face” meetings. Leave it to a group of bright, energetic engineers to shake off the negative and embrace the new normal. Here we are, all online together.
In five, half-day meetings, we assembled our technical steering committee, development teams, and EdgeX adopters/users to scope the features, technical debt, and architectural direction of the next release and general roadmap of EdgeX.
Ireland Planning
We follow an alphabetical naming sequence in our releases and select members of our community that have contributed significantly to the project to help with the naming process. This release was named by Intel’s Lenny Goodell and Mike Johnanson who have contributed immensely to the project, both in leadership and code contributions, over the past few years. Each release is named after some geographical place on the earth (city, state, country, mountain, etc.).
EdgeX 2.0 Major Release
During our planning meetings, the general themes, objectives and overall direction of the next release are the first thing we decide. Ireland will be EdgeX 2.0 – our project’s second major release.
As a major release, the Ireland release will include non-backward compatible features and APIs. This is, in large part, due to the fact that we began work in the spring of 2020 to implement a new and improved set of EdgeX micro service APIs. We call this new collection of APIs for each of the EdgeX micro services the V2 APIs (the V1 APIs are currently in place).
The existing EdgeX APIs have been in place since its very first release in 2017. The V2 APIs will remove a lot of early EdgeX technical debt and provide a better informational exchange. While we began the implementation this past spring, it will take the community until the spring release to complete the V2 APIs. The new APIs will also allow for many new, future release features. For one, the request and response object models in the new APIs are richer and better organized. The models will better support communications via alternate protocols in the future. The V1 APIs will also be removed from the EdgeX micro services.
Because this is a non-backward compatible release, we are taking the opportunity to remove as much technical debt and include as many desired non-backward compatible features as possible. This includes:
- Removal of archived/deprecated services like the Supporting Rules Engine and Logging services
- Removal of support for MongoDB (we have used Redis by default since our Fuji release)
- Support for device services to send data directly to application services
- Update configuration values and structures so they are more consistent with one another
- More appropriately name properties, objects, services and artifacts
New Features
In addition to the new V2 APIs, what is going to be in this major release? This list is long and I encourage those with a need for all the details to have a look at our documentation on our Wiki site, but here are some of the major new features:
- Device services (our “thing” connectors) will send data directly to our application services via message bus (versus REST) that prepare the data for export (to cloud or enterprise systems) and local analytics packages (rules engines, predictive analytics packages, etc.). Optionally, the data can also be persisted via our core services locally. This will help improve latency issues, allow for better quality of service, and reduce storing data at the edge when it is not needed.
- We are improving the security services to allow for you to bring-your-own certificates (in Kong for example), provide abstraction around our secret provider (and make sure that abstraction is used by all services in the same way), secure admin ports and more.
- Application services that prepare sensor/device data for cloud and enterprise applications (north side systems) will allow for conditionalized transformation, enrichment, or filtering functions to be performed on exported data.
- A number of device services have been recently contributed to EdgeX. We have new connectors for Constrained Application Protocol (CoAP), General Purpose Input/Output (GPIO), Universal Asynchronous Receiver-Transmitter (UART), and Low-Level Reader Protocol (LLRP) that are under review and will be made available in this release cycle.
- This release will include an example of how to include AI/ML analytics into the platform and data flow of EdgeX.
- Our EdgeX user interface will include new data visualization capability and a “wizard” tool to help provision and establish new devices in the EdgeX instance.
Additional Improvements
In addition to scoping and planning for new features to the platform for the Ireland release, the community also decided to address additional needs of our user community in this release.
- Because this Ireland release will be non-backward compatible with our current Hanoi and any 1.x version of EdgeX, we are also going to provide some tools and documentation for helping adopters migrate the existing release databases, configurations, etc. into the new 2.0 environment.
- We plan to increase our interoperability testing, especially around our use of 3rd party services such as Kuiper, and provide some scalability/performance guidance as it relates to the number of connected things and how much sensor data can be passed through EdgeX from those things.
- Our DevOps team is going to explore GitHub repository badges to provide adopters/users with better confidence in the platform.
Jakarta Release and Beyond
During these semi-annual planning meetings, the focus is squarely on the next release. However, we also take the time to take stock of the project as a whole and look into the future and roadmap where the project is heading a year or more into the future.
At this time, the community is forecasting that the Jakarta release – scheduled for around the fall of 2021 – will be a “stability release.” Meaning, Jakarta will probably not include any large enhancements. Its purpose will be to provide a release that addresses any issues discovered in the EdgeX 2.0 release of Ireland. We also hope that Jakarta will be our first ever Long-Term-Support (LTS) release. And with an LTS release, we hope to begin the implementation of an EdgeX certification program.
The EdgeX LTS policy has already been established and we have indicated to the world that once we have an LTS release, we plan to support that release (with bug fixes, security patches, documentation and artifact updates) for 2.5 years. That is a significant commitment on the part of our open source community and the stability release will help us achieve that goal.
The certification program is one we have envisioned for a number of years. The idea is that we eventually want to get to a point where a 3rd party could create and provide a replacement EdgeX service and the community would help test and validate that the service adheres to the APIs and criteria for that service and thereby is a suitable replacement in an EdgeX deployment. In order to deliver the certification program, the community feels we need to get to the stability that an LTS release provides with the product.
Wrap Up
It’s been a heck of a year. Despite the significant global pandemic and economic challenges, the EdgeX community did not miss a beat and managed to complete its goals for the year (2 more successful releases). And with our fruitful planning meeting, despite it being held on-line, the community has plotted a path for an even more successful 2021 that will start with the delivery of EdgeX 2.0 in the spring.
As always, I want to thank the members of the community for their outstanding efforts and talents, patience and commitment and professionalism. You could not find a group of people that are more fun to work with. Here is wishing that in 2021, we can resume actual “face to face” meetings. Happy holidays and a happy new year to everyone.
To learn more about the EdgeX Foundry releases and roadmap, visit https://www.edgexfoundry.org/software/releases/.
