Premières actions dans le cadre Phoenix

damien.hartmann · Octobre 4, 2020, 5:11

Nous avons entamé hier à l’issue du Forum Fédération les échanges sur les points de focalisation initiaux dans le cadre de ce vaste projet qu’est Phoenix.

Voici les deux points initiaux sur lesquels nous prévoyons de lancer les activités :

Détailler les cas d’usage

Pour le moment nous en avons identifié trois sur la page vitrine :

service spatial vers spatial : fournir de la capacité de calcul et de stockage pour des systèmes orbitaux qui en sont dépourvus ou en faible capacité (par exemple, pour externaliser le calcul de trajectoire d’évitement de débris, en l’absence d’accès à une infrastructure au sol)

Service spatial vers le sol :

fournir une infrastructure de secours, en cas de non disponibilité de l’infrastructure terrestre (catastrophe naturelle, cyber-attaque, bande passante contrainte…), pour assurer la continuité d’activité.

fournir de nouveaux types de services, en proposant une puissance de calcul significative avec une latence minimale (satellites en orbite basse), disponible en-dehors des zones denses et bien couvertes par les réseaux classiques.

Il faut clairement rentrer dans le détail de chacun, et en étudier d’autres, et les faire passer par un filtre de viabilité économique et de pertinence en terme de réponse aux attentes utilisateurs.

2. Etendre la bibliographie des projets open source existants
Il n’y a pas à priori de projet existant open source qui couvre la totalité du scope de Phoenix, mais il y a de nombreux projets qui en couvrent des briques. Quelques uns ont été listés sur la page vitrine, chacun devra être catégorisé et étudié pour sa pertinence à servir, ou non, dans le cadre du projet.
On peut déjà commencer par les classer par grande partie.

Je vais commencer par créer un tableur dans NextCloud pour le point 2., et un document texte pour le point 1.

Toute suggestion pour améliorer l’approche est bienvenue

fabio.mainolfi · Octobre 22, 2020, 1:29

Bonjour,

Il faudrait une analyse fonctionnelle permettant de définir les différentes composantes PHOENIX (segment spatial, segment sol, télécom, gouv, etc.), mais avant il faut définir des spécifications système qu’on pourra décliner vers les différents sous-systèmes. Sans spéc pas de développement….

Pour définir ces spécifications on doit définir les services visés.

Le document sur les cas d’usage commencé par @damien.hartmann donne pas mal de pistes mais aussi il me fait poser des questions. Par exemple je vois une différence entre service, fonctions et cas d’usage. Les cas d’usage devraient être une réalisation du service à travers les fonctions, ou un lien fonctionnel entre les utilisateurs et le système.

N’y connaissant pas grand-chose à l’IT et au services apportés aujourd’hui par le cloud (même si j’en fais usage comme tous), j’ai essayé de comprendre les implications des mots magiques XaaS (IaaS, SaaS, PaaS, DaaS, SECaaS, etc.) sur l’infrastructure.

Cet article (surement simpliste) vulgarise le sujet et donne une classification qui pourrait être utile pour déterminer les cas d’usage, les fonctions et les spécifications (pas que techniques mais aussi les entrées pour le modèle de gouvernance) :

Si on suit cette logique, on pourrait dire que le « service spatial vers spatial » est un cas d’usage des services IaaS (il y a en a d’autres en fonction de l’utilisateur). Il faudra donc traiter les composantes Data Center, Network & Storage, Physical Servers, Virtualisation.

Chacune de ces briques va avoir des fonctions, des contraintes, des spécifications qui vont se décliner sur la définition du segment spatial, du segment sol, telecomunications etc….

Je pense qu’il faut qu’on essaye de structurer un trade-off services / cas d’usage / contraintes.

fabio.mainolfi · Octobre 22, 2020, 1:33

IaaS = Infrastructure as a Service
SIaaS = Space Infrastructure as a Service

SDaaS = Space Data as a Service

XaaS = X as a Service
SXaaS = Space X as a Service …

tid · Octobre 22, 2020, 4:23

GSaaS = Ground Segment as a Service (https://leaf.space, https://aws.amazon.com/ground-station/)

damien.hartmann · Octobre 22, 2020, 8:06

OK je vais vous proposer un « cloud 101 », il peut facilement y avoir confusion ici.
Sur les XaaS, on confond modèle d’architecture et service / cas d’usage final.

Exemple très simple : un service de messagerie (Exchange, Gmail…) peut être supporté par une archi « tradi on premise », coloc, hosté, IaaS… jusqu’au SaaS. Quelle que soit l’archi derrière, c’est le même service qui est délivré, ce sont simplement les modalités d’administration et de gouvernance (et financières) qui changent.
C’est exactement ton diagramme sur la pizza, qui illustre très bien cela : cas d’usage = manger une pizza. Archi pour délivrer sur ce cas d’usage : made at home, take & bake, etc.

Le « aaS » s’oppose très simplement au modèle traditionnel d’acquisition par investissement, et s’appuie généralement sur la mutualisation des infrastructures. Par principe, dans le cas d’un cloud (une « infrastructure informatique mutualisée »), on fournit du aaS. Le cas d’usage derrière peut être de l’archivage aaS (c’est en-dessous du IaaS ou du CaaS en terme d’archi), de la sécurité aaS (qui va généralement s’appuyer sur du SaaS), ou plein d’autres choses.

Pour aller sur le cas d’usage spatial vers spatial : si c’est du calcul de déviation de trajectoire, ça sera certainement du FaaS (Function as a Service, archi) qui transforme le noeud en calculatrice (service de calcul). S’il s’agit de stocker des images d’observation de la terre, ce sera du IaaS (archi) qui fournit un service de stockage. S’il s’agit d’offrir un lien de communication, ce sera du PaaS ou du FaaS qui fournira un service de routeur ou d’équilibrage de charge.

Est-ce que c’est plus clair comme cela ? Tous les aspects d’architecture sont pour moi un peu plus loin dans le phasing projet, pour le moment je dirais qu’il faut continuer à se focaliser sur les cas d’usage. Et en effet, je dois organiser un peu mieux le document sur les cas d’usage, qui pour le moment est un support de brainstorming bordellique

fabio.mainolfi · Octobre 23, 2020, 11:42

Merci beaucoup pour ces explications Damien. Je trouve cette discussion super intéressante car je viens de me rendre compte qu’on utilise les mêmes mots pour parler de choses différentes et cela est lié surement au croisement de cultures.
J’ai l’impression que cela est le cas pour « services » (diffèrent pour moi des fonctions du système) et « architecture ».

Par exemple lorsque je parle d’architecture je ne me réfère pas à l’architecture du cloud mais à celle du système de télécom par satellites (segment sol, segment spatial, segment utilisateur, etc…) qui contribue à assurer un ensemble de fonctions du cloud (ça correspond à une partie des services de l’architecture cloud? ) .

Je suis complètement d’accord sur le fait qu’il faut commencer par identifier tous les cas d’usage possibles et leurs utilisateurs (même si j’ai la tendance à penser qu’il s’agit à 90% de ceux qui existent pour le cloud terrestre et que la partie spatiale doit être vue à comme une partie d’une infrastructure plus large).

Par contre je pense qu’il faut commencer à réfléchir sur comment passer de ces cas d’usage à la structuration du projet pour permettre au maximum de personnes de participer. Il ne s’agit pas de définir l’architecture du cloud mais de bâtir la méthodologie qui permettra de descendre de plus en plus dans le détail du système (Trade off cas d’usage -> trade-off architecture cloud & trade off gouvernance -> trade off architecture système de télécom par satellites -> Trade off sous-systèmes ->etc.).
Il s’agit donc de formaliser le processus d’ingénierie système. Ce sujet a déjà un peu été abordés sur le forum (Méthode de conception : Model Based System Engineering)

damien.hartmann · Octobre 25, 2020, 4:33

Au sujet du vocabulaire, je n’ai pas forcément été très précis moi-même : quand on parle d’architecture d’une infrastructure IT, on évoque ses différentes composantes serveur, stockage, réseau, middleware, système d’exploitation… Mais au final, selon ce qu’on inclut dedans, on arrive à différents types de services IT (« bare-metal », IaaS, PaaS, etc.).

J’étais en phase avec toi sur le sujet initialement, mais suite à une remarque de @loic.fejoz pendant la session breakout dédiée du Forum Fédération, il faut peut-être prendre en compte le fait qu’il n’y aura pas de viabilité économique (même à long terme) à la majorité de ces cas d’usage à partir de l’espace.
Après on peut se dire qu’on n’a pas besoin de regarder la viabilité économique, et qu’il faut bien penser PHOENIX comme une extension pure et simple du cloud terrestre, sans limitations liées aux contraintes de l’orbite.

Sur la formalisation du processus d’ingénierie système, @loic.fejoz comme tu es l’un des grands disciples du sujet, est-ce que tu es partant pour animer une première réunion de travail sur le sujet ? Est-ce que je peux lancer un Doodle pour une réunion de travail dédiée d’1h30 ou 2h dans les prochaines semaines ?

fabio.mainolfi · Octobre 25, 2020, 6:01

Effectivement la viabilité économique va être un gros sujet à traiter

. Cependant cela est vrai dans une approche classique mais pas si on cherche à produire des externalités vers d’autres acteurs. Leurs retours direct pourrait alimenter leur intérêt et leur contribution économique de maniere durable.
En gros il faut chercher des modèles pour tous les utilisateurs. Gros chantier à traiter mais peut-être après la démonstration

damien.hartmann · Octobre 25, 2020, 7:45

Très basiquement, si on vise à fournir du IaaS et du CaaS sans se soucier du coût associé à les opérer en orbite, on couvre 99% des besoins demandés à un cloud. A partir du moment où on met à disposition des machines virtuelles et des conteneurs, on peut proposer n’importe quel service mentionné précédemment, de l’appliance de sécurité à l’archivage longue durée, en passant par des bureaux virtualisés.
Et donc dans ce cas, à mon sens le projet se transforme bel et bien en « comment on met en oeuvre OpenStack ou OpenNebula dans un système orbital. » Il faudra définir quelle distrib Linux on utilise (Debian est très utilisé par les hébergeurs), et « on est bon ».

Côté architecture derrière, se pose la question de faire des noeuds tout intégrés (compute + stockage + réseau) ou est-ce qu’on sépare la partie réseau (des satellites qui seraient dédiés à la communication inter-noeuds potentiellement, en liaison optique, et d’autres qui font le relais espace-espace et espace-sol, en liaison radio). Ces points sont concrètement des sujets sur lesquels on peut déjà travailler, par exemple en commençant à faire un schéma global du système.