SlapOS
Présentation
La brique technologique SlapOS est une solution de Platform-as-a Service (PaaS) pour les applications critiques ou réparties déployées en edge ou en multi-cloud. C’est une solution 100 % libre (open-source) fondée sur le logiciel libre SlapOS (https://slapos.nexedi.com). Elle est au cœur du déploiement en multi-cloud du système de facturation d’une société d’autoroutes avec 2 millions de clients. Elle est également au cœur du déploiement en edge du logiciel de gestion de la production d’un grand constructeur automobile. Elle a permis le passage en edge d’une solution d’espace de travail collaboratif initialement disponible en SaaS. Elle sert à déployer des réseaux privés ou publics virtualisés 4G/5G avec des services de edge pour la communication répartie.
A quoi sert-elle et que peut-on faire avec ?
Cas d’usage « opérateur de SaaS » : avec SlapOS, le développeur d’un logiciel libre ou propriétaire peut transformer en quelques semaines son logiciel en service de SaaS déployé sur une infrastructure multi-cloud (ex. Scaleway, Rapid.Space, OVH, AWS, Alicloud, Azure, etc.) ou sur une infrastructure de edge. Le modèle de PaaS de SlapOS est compatible à la fois avec un déploiement dans des machines virtuelles ou en bare metal.
Cas d’usage « reproductibilité d’application critique » : avec SlapOS, l’exploitant d’un logiciel de gestion critique peut s’assurer de la reproductibilité de son déploiement sur n’importe quelle infrastructure de edge ou de cloud. Cela permet d’éviter la situation où, après le départ de développeurs ou d’administrateurs système, plus personne dans une entreprise ne sait comment réinstaller un logiciel critique au fonctionnement de cette entreprise. Cela permet également, en cas de panne majeure d’un opérateur de cloud (ex. Google en 2023 à Paris), de redéployer rapidement le logiciel chez un autre opérateur ou en interne.
Bénéfices
Le code 100 % libre de SlapOS garantit une indépendance totale par rapport aux fournisseurs de clouds publics. Il facilite le déploiement dans des régions (ex. Chine) inaccessibles à certains opérateurs. Il permet également des déploiements de services de edge ou de cloud dans des environnement déconnectés d’Internet. Il offre ainsi tous les avantages d’un cloud en termes d’économies d’échelle en évitant la rigidité des modèles de déploiement des grands clouds publics et leur résilience limitée.
Les infrastructures de Edge communément utilisées comportent aussi bien des micro-serveurs de type Raspberry Pi, Olimex ou encore des serveurs de edge de puissance comme le EdgePOD de Rapid.Space (https://shop.rapid.space/product_module/497/Resource_viewAsShop) voire des rack de serveurs de Big Data issus du projet Open Compute Project (OCP).
L’ensemble de la configuration du déploiement d’un service SlapOS peut être réalisé avec « Theia », un environnement intégré de développement (IDE) en mode Web créé par la société TypeFox et distribué par la fondation Eclipse.
Le déploiement avec SlapOS en multi-cloud ou edge couvre l’ensemble du cycle de vie d’un service de edge ou de cloud, du « build à la facturation ». SlapOS automatise ainsi douze facettes :
- build : reconstruction, à partir du code source, du binaire exécutable sur toute plateforme (distribution, version, architecture de CPU, etc.) ;
- allocation : choix du serveur ou de la machine virtuelle où sera déployé un service de cloud ou de edge en fonction de critères techniques ou juridiques ;
- instanciation : création d’un nano-conteneur permettant l’exécution d’une instance du service de edge ou de cloud en minimisant l’usage de ressources de l’infrastructure ;
- configuration : génération des fichiers de configuration du service précédemment instancié ;
- orchestration : configuration des interconnexions mutuelles entre plusieurs services instanciés et formant ensemble un service complexe cohérent (ex. connexion automatique du serveur d’application à la base de données et au service de haute disponibilité) ;
- monitoring : définition des objectifs de qualité du service (ex. temps de réponse) et surveillance de la conformité effective du service à ces objectifs ;
- self-repair : reconfiguration du service (ex. réallocation, allocation de nouvelles instances, etc.) afin d’atteindre les objectifs de qualité du service lorsqu’il a été détecté qu’il n’étaient plus atteints ;
- disaster recovery : reconstruction d’une instance à partir d’une sauvegarde en cas de destruction d’une partie de l’infrastructure ;
- comptabilisation : évaluation des ressources utilisées par les services déployés sur un serveur afin de piloter finement l’allocation d’autres services ;
- suivi d’incident : génération de ticket d’incident en cas de non-conformité d’un service aux objectifs de qualité définis par le monitoring et suivi de la résolution de l’incident ;
- test : vérification de bout-en-bout que l’ensemble des onze autres facettes d’un service de edge ou de cloud ne présente pas de régressions lors d’une mise à jour du code du service ou du code de l’infrastructure ;
- facturation : génération de la facture interne (contrôle de gestion d’un edge cloud privé) ou externe (edge cloud public) lié à la consommation de ressources ou la tarification du service.
Ces douzes facettes sont couvertes très simplement au sein d’un environnement déployable sur le cloud, sur le edge ou en quelques secondes sur l’ordinateur portable du développeur dans son « home directory ». Nul besoin d’installer un grand nombre de dépendances ou de nombreux logiciels sur de nombreux serveurs pour simuler et reproduire l’ensemble des facettes du déploiement en edge ou en cloud.
Cas d’usage et valeur ajoutée
Netframe a porté son SaaS en edge en quelques semaines et peut ainsi proposer un « digital workspace » déployé en mode edge pour garantir des besoins de résilience, de souveraineté et de protection du secret des affaires.
Toyota exploite en mode edge sur un réseau fermé (déconnecté d’Internet) une solution de gestion reproductible, déployée avec SlapOS avec tous les automatistes typiques d’un PaaS sur le cloud mais aussi avec des garanties de secret des informations bien supérieures à un déploiement sur le cloud.
SANEF exploite une solution critique de facturation déployée sur des clouds publics en mode mulit-cloud avec une gestion du cycle de vie de bout en bout (« build à la facturation ») avec des garanties de qualité, de passage à l’échelle et de reproductibilité mises en oeuvre par des tests automatiques.
Stellantis exploite dans certaines de ses usines une solution de gestion de production déployée en edge dans des régions où l’accès Internet n’est pas disponible de façon continue et dans des régions où les grands clouds US n’ont pas de point de présence, ce qui contredit certaines réglementations qui exigent un stockage local des données personnelles.
Informations complémentaires
Spécificités organisationnelles
- Ressources mobilisables par le consortium ?
Un ingénieur Nexedi dédié pour assurer le support, des serveurs de edge
- Temps hommes ?
3 mois homme d’assistance par Nexedi sur 12 mois
Spécificités techniques
- Normes techniques : C, C++, Go, Java, Javascript, Python, Rust, Ruby, FORTRAN, PHP, Node.js, Quick.js, Flask, Django, Drupal, WordPress, Zope, LAMP https://lab.nexedi.com/nexedi/slapos/-/tree/master/stack
- Documentation https://handbook.rapid.space/rapidspace-Learning.Track
- Le code source est disponible sur Gutlab: https://lab.nexedi.com/nexedi/slapos
- L’usage de SlapOS suppose de disposer du code source de l’application à déployer avec SlapOS et de développeurs connaissant bien ce code source. La licence de ce code source peut être libre ou propriétaire. SlapOS n’oblige pas à faire du logiciel libre.