Golioth presentation on service based architecture

Training
1

I attended the Embedded Open Source Summit a few weeks back, and one of the better presentations I saw was by a dev from Goliath who was talking about a service-oriented architecture with Zephyr.

The presentation was great! And I was wondering if Goliath had any sample repos that demonstrated this architecture. For example, services without public API’s, which communicate over ZBus, or whatever IPC mechanism takes its place.

Admittedly I did poke around, but I couldn’t find anything that matched the concept. Then again, I very well could have missed it.

This architecture really shines in terms of scalability, specifically across multiple Zephyr projects. For example, he mentioned services, and in my mind, those services could be part of a sort of distributed system where each service is its own repo in the form of a Zephyr module. The various Zephyr projects could then import those services as part of their manifest, which in turn increases reuse across products.

I’m glossing over a lot of details, but that was at least my takeaway. In any case, I just figured I would say nice job and also check to see if there were any examples that demonstrated this concept.

Thanks!

3

Hey @Bert!

Thanks for your kind words and glad to hear you found the talk useful! At the moment, we don’t have an example that uses this architecture. This talk draws mostly on my experience at previous employers. Our main firmware work at Golioth is our SDK, where it doesn’t make sense to structure it as a service (although one could certainly build a service on top!). We may end up using something like this in our reference designs, but at the moment we don’t have any examples.

I think packaging the services into individual Zephyr modules is a great idea. Previously, I’ve developed them as part of a monorepo, where the various apps would use CMake and Kconfig to choose which services to include. I think there are advantages and disadvantages to both approaches, and which one to use depends on your particular organization and usecase.

Happy to talk further about this if you have any more questions or thoughts!

Best,
Sam