heborras
commented
6 years ago Hey, so my design thinking at the beginning to use multiple services was mainly motivated by:
- Encapsulating each part of the project in its own service adds to the overall stability
- Each part can be run independently of one and another, making debugging and developing single components easier
- Using SystemD as a service manager gives us a lot of leverage towards future development. Because it can do things like: Dependencies between services, automatic service recovery, management of many services at the same time, provide logging and exposes a CLI.
- And I already knew how it worked
Obviously this has drawbacks, as @lukicdarkoo mentioned, the communication overhead, packaging difficulties, the potential jungle of services we are manoeuvring ourselves into, etc.
Personally I think, that using many services provides us with a flexibility that we can benefit from. In addition to being able to reuse standard software from Debian. My proposal for the future would be to rather add services and invest time in making full use of SystemD. As compared to merging currently separated services and dealing with the scheduling within the applications. We are after all not writing a high-performance computing application.
What are your opinions on the matter?
lukicdarkoo
Currently, CosmicPi software has 4 services: UI, MQTT, Core and database cleaner
New UI consist of a static part, REST and I would like also to add WebSocket to easily push live data. That would increase the number of services that run on Raspberry Pi to 6.
Multiple services introduce communication cost, memory usage overhead and complexity (managing multiple services, packaging, compatibility issues). On another hand, multiple services can be developed in different programming languages and a user has a better control (eg. can stop/start service independently).
Why are services separated? What is the future plan?