Good morning everyone. Looking forward to next week’s technical meetings in London. Really excited how far this community has already come and the energy that seems to be building with regard to EdgeX.
In this post, I would like to provide my take on what I believe is a realistic MVP set for our first release targeted for October and code named Barcelona. This will be the focus for next week. I have had discussion with a number of chairs and I want to give my perspective and attempt to set the table for some great discussion and decisions to be made next week. This perspective comes from what I hear from the community, what I see as the community involvement to date, my knowledge of the current code base, and my estimates on the lift to accomplish the work being proposed.
There is a ton of work that could be done and a lot we want to accomplish long term. The important question for this first release is what must be done and done by early October!! So it is time reduce our appetites and lock in our focus.
I’d like to get your reaction and get a discussion going on these channels (along with Rocket Chat). The more we can exchange on it now, the quicker and more successful our meeting next week can be.
I would like to thank John Walsh, Tony Espy, Janko Isidorovic, Andy Foster and many others that have started to layout their perspective working group goals and outline their MVPs. My suggestions below are really taking from that work and intersected with my perspective.
Barcelona Goals and MVP as seen by the former Fuse Lead Architect
· Stabilize the platform
· Build community understanding of the platform
· General majority agreement on the architecture
· General majority agreement on micro services and APIs
· General majority agreement on the development of an open, platform independent, technology agnostic platform for the IoT/edge
· General agreement on temporary performance targets
Minimum Viable Product (MVP)
· Review and agree/adjust micro service APIs
· Review and agree/adjust object models
· Improve/increase documentation especially for areas of extension (DS SDK, Export Services)
· Harden/stabilize the platform
o Works properly for the intended use case (it may not be 100% complete implementations for all use cases or parts of a protocol for example, but it provides enough implementation to sustain the demo use cases for Barcelona and could support extension to the full needs or protocol in the future)
o Handles errors and exceptions gracefully
o Contains proper unit and integration tests (lacking in DS, supporting services and others)
o Follows good coding standards, and is well documented (following some prescribed standard per programming paradigm)
o Performs within the target measures established for Barcelona
§ Examine Kura in detail and adjust performance targets accordingly
· Deliver Docker containers that run on Intel chip for Linux, Window, Mac
· Deliver Docker containers that run on Arm chip for Linux
Device Service / DS SDK
· Deliver initial set of 7 Device Services based on Dell contributions (Modbus, BACnet, Bluetooth, SNMP, MQTT, Serial (Fischertechnik), Virtual)
· Clean up SDK (and DSs)
o Improve documentation
o Merge device-sdk into SDK tools
o Improve tooling (Eclipse Plugin)
o Cleanup scheduler
· Remove redundant code from Device Services/SDK to shared libraries
· Redo/refactor Bluetooth and BACnet DS to be single micro service
· Additional DS provided by additional community participation
Core & Supporting Services
· Clean up some minor issues
o Logging OOM, Remove Device Manager, etc.
· Implement configuration callbacks (allowing for configuration changes dynamically without service restart
· Provide first Go replacements for Data, MetaData, Command (Dell has a start to these already)
Applications (including Export Services, Rules Engine/Analytics)
· Pick and provide at least one cloud connector (Azure IoT Hub has been prototyped by Dell)
· Offer MQTT, REST, ZeroMQ export
· Offer JSON, XML, CSV (not done yet) formats
· Improve module for encryption options
· Deal with potential number of readings, number of client scale problem
· Implement 2nd cloud connector (ex: Amazon Greengrass, Watson, ???)
· Add additional format offering (ex: Haystack, etc.)
· Add hyperledger export option
· In general, define the EdgeX security story but postpone a lot of implementation to California
· WG to agree on requirements
· WG to agree on what security features are going to be in EdgeX and what’s going to be provided by the platform that EdgeX runs on (example: the underlying platform must have a keystore)
· WG to define what EdgeX security service(s) need to be eventually implemented
· WG to define what security hooks need to be added to the existing micro services
o How and to which services would APIs communicate with
· WG to define what standards, protocols, etc. are going to be adhered to and followed by EdgeX (ex: IIC specs, OAuth tokens, etc.)
· WG to provide guidance on how security features can/should be tested
· Add stubbed hooks into micro service code
· In general, define the EdgeX system management story but postpone a lot of implementation to California
· WG to agree on requirements
· WG to agree on what features are going to be in EdgeX and what is reserved for OS, 3rd party systems, other open source systems, etc.
· WG to define what system management services need to be implemented as part of EdgeX (if any)
· WG to define what system management hooks need to be implemented
· WG to define any system management standards that will be followed/used in system management implementations (ex: LWM2M)
· Add some simple system manage hooks/capability into BaseService of EdgeX micro services (Dell has already done some POC work with things like start, stop, …)
· Insure part of code review/code check is to insure proper unit/integration tests for the code are provided (backed up by code coverage statistics)
· Create a blackbox testing framework to insure the APIs between services are not broken and to be able to measure performance of a micro service and across multiple micro services to insure targets are achieved
· Automate blackbox testing on all micro services with each build
· Agree on a base set of policies and procedures around code check in, code approval, governance, etc.
· Utilize the existing LF build process with some additions noted below.
· Create Docker containers and push them to Docker Hub via the build process
· Anoint a Bug Czar to setup a bug management process and monitor, track, and address incoming bugs (along with general support issues across media channels)
· Automate creation of ARM build/containers.
· Create a working group to define the use case and demo presentation
· Work with the community to get hardware, sensors, etc. donated for the demo
· Create a minimal user interface for EdgeX (could be based on Dell Fuse UI)
As we discuss the MVP, we should also capture what items we believe don’t fit within the constraints of Barcelona and gets moved to California.
California Release Goals
· Implement first security and system management services and tie to existing micro services
· Improve performance
· Introduce replacement services as appropriate (ex: Go Core)
· Demonstrate EdgeX in real world POC/Test Bed
Looking forward to the discussion. Safe travels to all attending London meeting in person.
Distinguished Engineer, Software Architect
Dell | End User Computing, Chief Technology Office (EUC CTO)
Office +1 512-723-6139, mobile/text +1 612-916-6693