Delivery: ~June 2018
The main theme for the California release of EdgeX is to provide a solid open source foundation for commercialization and deployment in a wide variety of Industrial IoT edge use cases.
Key to this is the first implementation of priority APIs and reference microservices for security and manageability. Another key theme for the California release is improving overall performance and lowering the baseline footprint of the code base. Work is currently underway for drop-in alternatives for key microservices (e.g. Core Services, Export and Device Services) based in Go Lang with a stretch goal being select implementations in C. Overall, the California release will improve EdgeX ease of use among a larger, more polyglot, development community.
Planned features to be delivered (as of January 2018 TSC Face-to-Face meeting).
EdgeX has been built to be cross platform. Some micro services (such as those written in Go) require compiling to the native platforms (cross compiling). Once the program artifacts for the platform have been created, they also need to be containerized (in Docker) and some of the containerization is platform dependent. Finally, it is also desired that the micro services be tested on their native platform. While virtual machines and simulation environments can allow functional tests to occur, some issues and performance metrics for that platform can only be identified when running on the target platform. This task therefore includes:
Today, while the community and users of EdgeX are free to deploy EdgeX as they see fit based on their use case/needs, the EdgeX community provides Docker container images and a docker-compose.yml file to help get and deploy EdgeX. Going forward, it is anticipated that the community will seek and even need alternate means of deploying, managing, and orchestrating the EdgeX micro services. Options include using Kubernetes, Swarm, Mesos, Nomad, to name a few. Additional support may be offered by system management tools or facilities. At this time, the community welcomes input and contributions in this area from the community and user groups, but has no firm plan to do work in this area by the California release.
While more requirements are needed, the overall performance targets for EdgeX are listed at the bottom of this page and include running all the core, support and application micro services in < 1GB or RAM on a 64 bit CPU, requiring less than 32GB of disk storage space, start (collectively) in under 1 minute and actuate from sensor collection to device trigger in < 1 second.
In order to accomplish these targets, it is believed the following work must be accomplished for the California release
Depending on the implementation needs of security (see below) and system management (see below), there may be a need to make changes to the existing micro service code in support of these facets. It is likely that each micro service will implement some sort of base service to provide data and system management functionality to the system management agent. It is hoped that security work will not require micro service changes but this could change depending on design and implementation needs.
A OS reverse proxy will be selected and integrated to EdgeX
Integrate with AAA service (see below)
With no (or very few) changes to existing micro services at this time
Currently looking at Traefik for dev/test and possibly NginX for prod
This will be for HTTP/S only (meaning security for MQTT and other protocols will not yet be provided)
An open source Authentication and Authorization server (s). (E.G., Keycloak, Dex, Hydra, …) will be selected and integrated to EdgeX
Prod deployment models will require integration with centralized AAA. Initial solution will be to integrate with reverse proxy
Data Protection Services via HashiCorps’s Vault will be integrated with EdgeX
This will provide Key Management, Certificate Services, Encryption
API abstraction to allow 3rd party implementation/extensions
Some additional research/work needs to be finalized for California around license, external CA support, local crypto library, bootstrap provisioning, local secure store for bootstrap credentials, unattended startup
System management API (action, alerts, metric) as discussed and outlined here
System management Agent
The target is to run all of EdgeX (all the services to include the virtual device service) on a Raspberry Pi 3 (1 GB RAM, 64bit CPU, at least 32GB storage space, running Raspbian Linux distro)
This is not an endorsement of the platform as our favorite or otherwise endorsed platform
It only suggests the general characteristics of a “developer community” target platform
This may not be entirely feasible without all Go replacements, but is the target and the development community will report back when/where this is not possible
For example, it is unlikely the target security implementation will fit on this size platform
Additional “developer community” targets
Startup in 1 minute or less (post OS boot – from micro service start to all services up and available)
Throughput for one piece of data (with one IP device connected by hard wire – versus WiFi) from data ingestion at the Device Service layer, through Core Data, to Rules Engine and back down through Command Service finally to Device Service for actuation will be < 1 second