Bonjour Gilles,
Pour rebondir sur notre discussion sur le forum d'en face, voici une idée plus concrète de ce que pourrait être une architecture de services/microservices dans le cadre de la gestion d'un observatoire. Chaque service est intégré dans son propre container Docker. La liste n'est pas exhaustive puisque n'importe quelle fonctionalité peut être, au final, transformée en service indépendant.
- Un service de communication avec le matériel. Typiquement, un serveur Indi offrant une interface de type Alpaca (API Rest). A moins qu'Indi ou Indigo ne proposent déjà ce type de solution.
- Un service de reconnaissance astrométrique. Genre ASTAP ou Astrometry.Net ; certains possèdent déjà des offres containerisées.
- Un service de mise au point automatique.
- Un service d'autoguidage.
- Un service de gestion des catalogues d'objets célestes
- Un service de scheduler pour l'automatisation
- Un service de mise à disposition des données météo/all-sky sur le web
- Un service de monitoring / watchdog
...
Il est possible de créer, pour chacun de ces services, un ou plusieurs autres services chargés de l'interface utilisateur : une carte du ciel pour gérer le service des catalogues d'objet, des widgets pour les données météo/all-sky, une interface d'administration (type Indi Web Manager) pour le service de communication avec le matériel, une interface graphique pour le séquenceur... Une interface UI peut piloter le tout, qui peut être scindé en services pour l'interface mobile, pour l'interface desktop, pour une web API, etc.
En fait, il suffit de reprendre toutes les fonctionalités de Nina, CdC , Prism et cie. Quasiment toutes peuvent être des microservices potentiels.
Le gros avantage des services containerisés est qu'ils peuvent être développés indépendamment, dans la technologie la mieux adaptée (du C/C++/Rust pour du calcul intensif, du NodeJS pour du backend web, du React pour le front-end, etc.), avec leur propre cycle de dev. Ils peuvent aussi être repris depuis des projets open-source et containerisés.
Autre avantage, ils peuvent être décentralisés. Rien n'oblige à ce que tous les containers soient sur la même machine. On peut imaginer que seuls les containers nécessaires au pilotage de l'instrument soient sur un Raspi sur le télescope, les containers gérant l'abri/la coupole/la satation météo, la all-sky sur un autre Raspi, les containers de calculs dans un PC plus puissant dans l'abri, les containers des interfaces graphiques sur un NUC dans la maison, etc.
C'est une architecture très souple mais un peu complexe.
Vincent
