EdgeX F2F TSC Meeting and the evolution of the EdgeX Cadence
Written by Dell’s Jim White, EdgeX Foundry TSC Member and Chair of Core Services Working Group
Last week (Jan 16-18), the EdgeX Foundry Technical Steering Committee (TSC) had our 4th face-to-face meeting in Orlando. Our previous meetings were held in Boston (June), London (July) and Barcelona (October).
All of the EdgeX project business is conduct in an open fashion, so we invite anyone with input and something to contribute to join us in our face to face meetings. To that end, while we had 10 TSC members in attendance, we also 14 non-TSC members attend, with another dozen joining at some point during the week by conference call. The EdgeX technical community is certainly alive and well!
Our meeting topics were far and wide, but the central themes were focused on:
- The work tasks and duties around getting the California Release out (scheduled for June 2018)
- Architectural issues that need addressing for the California Release and beyond
California Release Planned
The California Release will include the first EdgeX security and system management features. There is much work to be done, but the committee agreed on the implementation of these first elements toward offering a more secure and better managed EdgeX platform by June:
- An open source reverse proxy will be selected and integrated in to EdgeX to protect against unauthorized access of the micro service REST APIs.
- An open source authentication/authorization service will be incorporated in to EdgeX and be used by the reverse proxy, but other elements of EdgeX in the future.
- An open source data protection service will be integrated in to EdgeX to provide key management, certificate services, and encryption capability – which can and will be used by several elements of EdgeX.
- Each micro service will be outfitted with a system management API that allows it to set the service’s administrative state, stop the service, or get/set its configuration among other operations.
- A system management micro service (call the system management agent) will facilitate 3rd party requests (eventually in a system management API of choice like OMA LwM2M, SNMP, etc.) while also performing more broad operations such as restarting all micro services.
Architectural Resolutions
As with any software system, there are a number of architecture issues which need to be addressed – or on occasion readdressed – as the platform evolves. With EdgeX, we are learning that face-to-face meetings are a great place to tackle the architectural decisions where brainstorming, whiteboarding, and extended conversations over lunch/dinner/drinks can really help to resolve issues that don’t fit in our weekly working group conference calls.
The architectural topics discussed and resolved during our meeting last week include:
- EdgeX will officially support one main “reference implementation” of any micro service at a time going forward. With Go Lang micro services being created to help reduce the footprint, startup time, and performance associated to some of our Java micro services, the question was raised as to what happens to the Java micro services once the Go Lang replacements are ready? We decided that going forward, the community would have one main implementation of each micro service, but if others in the community were willing to help maintain/support other implementations, they could be retained as “alternate” implementations – otherwise they would be archived. EdgeX remains committed to its polyglot tenet – that is, any micro service can be allowed to be created using any programming language of choice. The reference implementation of each micro service will be the implementation that the community believes is the best implementation – regardless of language – while also meeting the API requirements and quality agreements for that service.
- EdgeX is starting to receive some sizable contributions. How do we take on large code contributions from the community? What’s the process for ingesting the code, making sure it fits the current architecture (or plan-fully rethink the current architecture if necessary), and meets quality levels expected of the project? A new contribution process and tooling framework was designed by the community to deal with this need. More information will be made available on the Wiki as this is drafted and formalized.
- EdgeX uses Docker and Docker Compose for its deployment architecture today. What does EdgeX want to support in the future? The community agreed to continue to use Docker and Docker Compose but also allow members of our community to present alternatives and ideas for additional solutions – like Kubernetes – in the near future.
- With multiple Device Service SDK’s to be constructed in different languages over this release cycle, what elements of design should the different SDKs share and where can they be different? Our Device Services Working Group chairman is going to lead a requirements session followed by a design session in the coming months to bring some conclusions to this issue.
Other Significant Work
What else was covered in our face-to-face meeting? Plenty! You can see a deck of resolutions and action items here.
Additionally, if you want to see the agenda or listen to recordings of the meeting, you can also find them on our Wiki.
Other highlights include:
- We resolved to make the California Preview available by Jan 31st. The Preview will include the Go Lang Core service replacements and demonstrate, dramatically, improvements in micro service footprint, memory and CPU usage, and start up times. I’ll have another blog post in the near future to outline the performance improvements we are seeing with Go Lang.
- In addition to security and system management, the California Release will include more complete blackbox testing as well as performance tests, native ARM testing, SDKs in C and Go Lang, and improved documentation
- We revised and updated our roadmaps for the Delhi release (Oct 2018) and newly named Edinburgh Release (April 2019). Look soon to our project Wiki for details on these updates.
- Plans were made to participate, formally as a community, with presentations/demos at Hannover Messe and IoT Solutions World Congress among other potential conferences this year.
- We also resolved to meet again for our next face-to-face in June, right after the California release, to plan the Delhi release at a venue to be determined.
And We Had Fun!!!
Being a part of EdgeX has been a highlight to my career. The community of experts that participate in EdgeX Foundry are just plain good people to be around. There are some spirited discussions, but egos are always checked at the door in these meetings.
We always manage to get in at least one community dinner, and for this meeting, our dinner was at the top of the Orlando airport’s Hyatt hotel. Plenty of good spirits and spectacular views to go around.
A number of our community planned to go to Cape Canaveral to see a rocket launch on the last evening. Unfortunately, the launch was cancelled due to weather. But this gave us all an appetite to one day see EdgeX in “SpaceX” and come back to see another launch.
