Delivery:  ~ April 2020

The Geneva release is likely to focus on 3rd party service certification, platform and setup guidance relative to EdgeX performance measures, and high availability concerns.

Release Themes and Objectives

• Implement an EdgeX run service certification program on top of the self-assessment program implemented for Fuji.  This will allow third parties creating EdgeX services to verify their services as alternative or enhancing capability to those provided by the EdgeX open source effort. This will allow 3rd parties to add value (proprietary or open source) to EdgeX that customers can rely on to meet the EdgeX APIs and work without additional code change (enable a plug-and-play ecosystem). Various levels of certification are being considered, from micro service replacement certification (validating alternate or commercial implementations of EdgeX micro services satisfy API requirements along with performance metrics and quality checks) to full EdgeX deployments (for commercial versions of EdgeX). Additional certification processes may be developed around particular cross cutting features such as security.
• Providing EdgeX users guidance on platform needs, sensor data throughput and deployment based on performance metrics.  Specifically, with the Geneva performance testing apparatus, the EdgeX community will be able to answer these questions for the user:
  • 1) Will EdgeX fit on my system? - size of EdgeX services, infrastructure, etc. and hardware/platform requirements
  • 2) What is the speed of data through the system? - from device service sensor data ingestion to the rules engine and back down through command to another device service to trigger a put command, how long does this take?
  • 3) How many “things” can be processed at a time? – with caveats on the type of thing, type of data, etc.
  • These questions need to be answered on real hardware (both Intel and ARM)
• Improve EdgeX distributability and resiliency in face of issues or non-availability of some resources/services/etc. (typically for core and above services and not device services)
  
  • Insure all micro services follow 12 factor app methodology (see https://12factor.net/)
  • Allow services to be load balanced
  • Allow services to fail over
  • Allow for dynamic workload allocation
  • Allow services to live anywhere and be moved without lots of configuration to be changed in other services
  • Allow services to be distributed across hosts - and across API gateways (requiring service to service communication protection)
  • Support cross EdgeX instance command actuation (ex:  device X on EdgeX box A triggers action on device Y on EdgeX box B)
• Provide an alternate local analytics service (archiving the Java-based rules engine service)
• Address more vertical solution needs