Services IT visés par PHOENIX : IaaS et CaaS

Projets PHOENIX - infrastructure informatique orbitale
1

Lors de la réunion bimensuelle d’avancement de Phoenix, nous avons tranché sur les services IT à fournir par Phoenix sur lesquels nous allons focaliser le travail : Infrastructure-as-a-Service (IaaS) et Container-as-a-Service (CaaS).

IaaS Infrastructure as a service : mise à disposition de machines virtuelles, technologie dominante, qui impose infrastructure résiliente

CaaS container as a service : mise à disposition d’environnements complets, plus ou moins fractions de machine virtuelle, permet de nouveaux usages hyper focalisés sur les besoins, auto-résiliente et très peu dépendante de l’infrastructure physique. C’est la technologie montante aujourd’hui, amenée à remplacer le IaaS sur une majorité de services d’ici 5 à 10 ans.

Une fois qu’on offre ces deux services, on couvre 95% des usages offerts par un cloud informatique aujourd’hui (voir les discussions à ce sujet plus en détails dans ce thread).

Du point de vue architecture informatique qui va aller derrière (empilement de processeurs, mémoire, stockage, réseau, middleware logiciel…), de nombreuses architectures de référence existent déjà sur lesquelles nous allons pouvoir nous appuyer. Plusieurs technos open source existent pour le middleware (OpenStack, OpenNebula, etc.).

L’enjeu va être de modifier ces briques pour les adapter à notre infrastructure physique un peu particulière, en particulier en matière de lien entre les noeuds (latence de l’ordre de la milliseconde dans un datacenter classique) et en matière de puissance électrique, et donc de puissance de calcul, disponible (on parle de dizaines de milliers de kVA dans un datacenter classique).

Ces éléments nous permettront aussi de trancher un peu plus loin entre les deux services, le cas échéant : on risque de se rendre compte un peu plus loin que les contraintes sont trop fortes par exemple pour offrir les deux services depuis la même architecture, et qu’il faut se limiter à un seul (logiquement, le CaaS). Nous mènerons donc en parallèle de l’étude technique une analyse de « viabilité. »

Tout cela est écrit ici pour documenter le processus de décision et avancer, ça peut tout à fait être challengé :slight_smile:

2

Salut,

bon j’arrive après la réunion, j’en suis désolé, mais de mon point de vue, partir sur 2 niveaux de virtualisation dès le début, même pour une étude, c’est déjà partir sur trop compliqué, et c’est dépenser des ressources humaines sur une piste que l’on sait déjà plus couteuse et compliquée (le IaaS).

Le IaaS est couteux en terme énergétique par essence (multiplication des kernels, + grosses images, virtualisation de chaque élément) mais il est aussi compliqué à maintenir, à mettre à jour, surtout avec les contraintes de réseau que l’on va appliquer aux nœuds. Outre le côté plus complexe du IaaS, quel serait le besoin effectif ? avons-nous déjà identifié des fonctions clientes qui nécessitent une VM et qu’un conteneur ne peut faire ? ou ce besoin de IaaS est juste « au cas où »

Comme tu en fais déjà le constat, le CaaS sera amené à remplacer en bonne partie le IaaS, mais à mon avis ce n’est pas 5 à 10 ans, c’est beaucoup plus tôt que ca, même les solutions cœur 5G en cours de préparation partent sur du Kubernetes, c’est pour dire :smiley: 5 ans, si je ne me trompe pas, c’est aussi la cible officielle du lancement du service Phénix :slight_smile: Est ce que ça vaut le coup de partir sur un IaaS alors qu’on estime qu’il sera obsolète au moment de l’ouverture ? De plus, si le besoin se fait sentir des solutions comme KubeVirt pourront être étudiées et ajoutées pour lancer des VM.

Juste pour préciser, je n’ai rien contre les VM, elles ont leurs avantages, et il ne faudra pas s’empêcher de les utiliser pour nos besoins d’infra, ce qu’il ne faut pas faire à mon avis c’est proposer un service de IaaS.

L’objectif de Phenix est déjà (très) ambitieux, je serais donc encore plus partisan du Keep It Simple and Stupid et des choix pragmatiques: une limitation à des services Cloud native et une archi CaaS (voir KaaS) qui devrait répondre à 90% des besoins d’une première itération.

Une étude intéressante pourrait se faire sur l’opportunité de fournir du SaaS voir FaaS au-dessus du CaaS pour fournir du service à tous les clients tout en maîtrisant les socles logiciels et donc la sécurité, et limiter les fonctions de C/KaaS à des clients privilégiés.

On pourra rediscuter de tout ça à la prochaine réunion :slight_smile:

3 « J'aime »
3

Merci beaucoup pour les feedbacks David. En effet, en fin de réunion cette semaine, tout pointait vers le CaaS comme cible, mais on avait convenu qu’on ferait quand même une comparaison documentée avant de prendre une décision finale.
De mon côté je suis biaisé parce que mes clients, collectivités locales et santé, sont encore à 95% sur des applications fournies en IaaS, le reste en SaaS, et que les conteneurs semblent looooin… :slightly_smiling_face:

Pour aider à la comparaison, je viens de créer un embryon de tableau de comparaison entre les technologies, en prenant en compte le cadre particulier de Phoenix (on trouve des centaines d’articles de comparaison de ces technos dans un datacenter terrestre). Je propose qu’on le complète au fur et à mesure qu’on avance dans l’étude.

Et entièrement en ligne sur le FaaS (généraliste). Pour le SaaS, de toute façon à partir du moment où on fournit du CaaS, quelqu’un sera en mesure d’en proposer par-dessus. Par contre il me semble que si on l’envisage dès maintenant, on va se focaliser sur des usages non pas polyvalents mais très focalisés, et à ce stade je ne suis pas sûr que ce soit pertinent.

2 « J'aime »
4

En partant sur l’idée de CaaS, j’ouvre un peu le sujet sur quel type de CaaS dans le sujet sur les Software Container Technology.

1 « J'aime »
5

Bonjour, je viens de voir l’échange sur le Forum. La question qui faut se poser c’est le niveau de maturité de vos applications. Si vous dites que vos applications ne sont pas aujourd’hui architecturé en microservice ou adapté pour etre hébergé sur du containers. Il vaut mieux intégrer de la VM en ayant une possibilité d’intégrer du CAAS en upper layer. (C’est ce qui se fait chez beaucoup d’hébergeur).
Dans les 5 a 10 ans. On compte une migration smooth des application vers du microservice. Pour celà une réarchitecture des applications est nécessaires. Je partirai dans un premier temps vers de l’hybridation en intégrant du IaaS et du CaaS. (Pour votre info le IaaS n’est pas synonime que de VM mais d’infrastructure sous jacente physique et réseau et wattercooling…). DOnc du IaaS vous en aurait toujours meme si elle sera absorbé par le CAAS au fur et a mesure.

6

Vu de ma fenêtre, cela prend en compte une hypothèse « on doit gérer le legacy ». Alors que dans notre design actuel on a choisi de prendre en compte que de toute façon les workloads qui seront envoyés dans Phoenix seront cloud native par défaut, le legacy VM dans l’espace étant négligeable (surtout du legacy bare metal dédié). Notre conclusion à l’époque : ça ne sert à rien pour nos cas d’usage de prendre en compte du legacy, autant partir tout de suite sur une archi moderne, efficace énergétiquement, et les use cases seront adaptés en fonction. Il n’y a pas à notre connaissance beaucoup de KVM, Hyper-V et ESX en orbite qui attendent leur migration vers un cloud orbital :slight_smile:

1 « J'aime »