Il faut degoogliser Internet, ok. Avec du logiciel libre, ok. Libre comme le discours, pas la bière, ok.
Brassage domestique
Je dois pouvoir micro héberger, sur un gros mutu PHP, sans compétences particulières, euh non, en fait.
Il est indispensable de garder le contrôle de ses données, et de décentraliser Internet. C’est une démarche politique et technique. Les deux ensembles. Une bouse technique, mais correcte politiquement, c’est un échec.
Parlons pognon
Vous voulez déposer une application sur Internet, et que des gens puissent l’utiliser. Ça va avoir un cout : en temps, en matos, en sous.
Le cout du développement, si c’est un logiciel libre, installé tel quel, sans modification, bah il est gratos, comme dans bière gratos.
Ensuite, il faut un serveur, et un branchement vers Internet. Avec les ordis de la taille d’une paume, et une ADSL à prix agressif, le cout d’un hébergement à la maison va être faible. Les offres entrées de gammes de nos hébergeurs nationaux (ou plus loin) sont elles aussi accessibles.
Concrètement, pour un service simple et peu sollicité, un hébergement peu cher aura des performances correctes.
Jusqu’ici tout va bien, le cout du développement et de l’hébergement matériel sont raisonnables.
Mais c’est que maintenant que l’histoire commence.
Notre temps
Vient maintenant la notion de maintenance.
Le développement, c’est ton temps, l’hébergement, c’est le temps des autres.
Le service va avoir des incidents, qu’ils soient matériels ou logiciels. De simples bugs, sur lesquels on peut s’assoir, ou des failles de sécurité, qu’il faut patcher rapidement avant que ça dégénère. Pour certains services, comme du SMTP, un incident, ça veut dire un bannissement, et donc un arrêt partiel du service. Un service compromis qui va miner du bitcoin en mettant à genoux le serveur, ça veut dire aussi un arrêt du service.
Un disque dur qui boude, un serveur qui se coince, ça veut dire restaurer un backup, et donc avoir fait un backup.
À un moment, vos utilisateurs vont utiliser votre service, sinon, il ne sert pas à grand-chose, et donc le secouer un peu, puis beaucoup. Ce n’est pas grave, vous centralisez les erreurs, enregistrez les métriques et faites un joli tableau de bord. Une première passe pour trouver des usages abusifs, puis finalement, ils vont atteindre de vraies limites, et ça va ramer sévère.
Là, l’hébergement de ce service va commencer à être pénible. Le cout du dev est gratos, le cout du matériel est symbolique, le cout de la maintenance explose. Que faire? Passer en force et surdimensionner les serveurs, mais ça veut dire tout réinstaller (bah oui, sans provisionning, sans conteneur, ça a un cout sympathique), et ça transfert un cout en temps vers un cout en sous. Avec plus de matos, ou du matos plus gros, ça va pouvoir secouer plus fort, avec plus d’utilisateurs à mécontenter, et de nouveaux drames rendus possibles par le franchissement de la première vague de drames.
Cramage
À cette étape, il est possible de cramer l’admin, qui va se trouver bien seul, avec plein de gens pour râler. Si c’est pour du support utilisateur, un forum et des grunts peuvent décharger une partie de la charge. Pour les serveurs qui pètent, bah, c’est compliqué.
Pour ne pas cramer un humain, une seule solution en avoir plusieurs, une équipe en fait. Pour rentabiliser, il leur faut donc plus d’utilisateurs et donc une instance plus grosse. Il sera humainement possible de gérer plus de matos et donc céder à la facilité de continuer de passer en force
Ce n’est pas sale de payer des gens. Que ce soit en micropaiement ou salarié par une structure associative. Ils mangent, payent un loyer et s’habillent de teeshirt trop cher à cause des dessins qu’il ya dessus.
Automatisation ou l’anti-luddisme
À cette étape-là, infra as code n’est plus une option.
Par contre, empiler du matos, juste pour gérer des pics d’utilisation, ça va devenir hors de prix, et c’est même probable que le code ne va pas gérer la répartition sur plusieurs machines. L’impasse va vite arriver.
En parallèle, un autre problème va arriver : la complexité des services. On est passé de l’ère des sites webs à celui des applications, et tout ne rentre pas dans l’http de l’an 2000, pour avoir du tchat, de la visioconférence, oui, ça va passer par les navigateurs webs, mais via websocket, webrtc et autres streamings. Cette complexité va faire exploser les couts de développement, et la complexité côté serveur. Cette fois-ci, Varnish ne pourra plus sauver votre développement de bourrin.
Les utilisateurs ont rapidement pris gout aux interfaces léchées des applications web des GAFAs. Essayez de faire passer un utilisateur non militant de Gmail à Squirrel mail, juste pour voir. Pour développer un service de qualité, il faut des compétences complémentaires (UX, graphisme, support, traduction, développement…) et tous ces métiers ne se payent pas tous de gloire, leur métier ne leur laisse pas forcément autant de temps et de thunes en rab, pour le consacrer au logiciel libre.
Le matos a changé d’échelle avec le remplacement des disques à plateaux qui se trainaient lamentablement par le SSD, et même avant qu’on se rende compte du changement par du NVMe. En face, de la fibre ou de la grosse 4G. Le matos est prêt à tout engloutir, ce ne sera ni le stockage, ni la bande passante qui vont ralentir la soif de pixels.
Donc, voilà, des hordes d’utilisateurs exigeants, avec des gros appétits, sont là pour apprécier vos services. Serez-vous à la hauteur?
Un nouvel espoir
Pour avoir une chance de réussir à proposer des services sympathiques en ligne, alternatifs ou pas, il faut d’abord mettre de l’ordre dans tout ce fatras.
Protocoles
L’idée de base est de ne pas avoir de monopole, il faut donc avoir des systèmes décentralisés, des machins qui causent entre eux pour profiter de l’effet d’échelle. Un réseau social fonctionne par ce qu’il y a déjà plein de gens dessus. Pour ça, il faut des protocoles, une locomotive pour tirer plein de monde, et des implémentations adaptés à des cas moins courants.
Bittorrent a parfaitement réussi ça, et Mastodon peut réussir si Pleroma arrive à se démocratiser. Peertube est fonctionnel, en déclinant le concept du pair à pair à la vidéo. Il faut voir ce que donnera IPFS.
Le mail est LE premier service distribué largement utilisé, mais le spam et la stagnation des outils libres qui ont permis l’apparition de gmail ont eu un effet dramatique. DKIM et SPIF sont maintenant un prérequis, mais l’arbitraire des gros serveurs est maintenant une menace permanente. L’incapacité du courriel à garantir la confidentialité des échanges, confirmée par l’échec de GPG, ont reléguer le mail au rôle de renouveleur de mots de passe.
Il faut des protocoles bien spécifiés pour être interopérables, et des implémentations qui scalent petit, et grand.
Étonnement, Gitlab et Gittea via git comme protocole permettent ça. Reste à normaliser la notion de fork et pull request.
De la distribution de service sans syndication efficace, bah, c’est juste de la dispersion.
De bons outils
Avant, on avait des disques qui ramaient, une pénurie de développeurs web, et des navigateurs pourrites. Donc pas de dev front. Il y eut ensuite l’épisode Flash + IE6, pour enfin aboutir à la modernité : HTML5 et les spécifications EcmaScript, la déferlante des smartphones, les disques qui vont trop vite et les gros tuyaux.
Pour les devs, on a maintenant des langages matures, des bouquins avec des gravures d’animaux dessus, des frameworks, des workflows pour gérer le code, et de plus en plus d’analyses statiques.
Il faut un écosystème logiciel suffisamment responsable pour avoir des bibliothèques maintenues et pas systématiquement trouées.
Qualité
Donc, pour proposer des services de qualité en ligne, il faut des technologies suffisamment répandues pour avoir un stock de développeurs, et une chance de reprise si le mainteneur a un pépin. J’ai fait des patchs Erlang, par vice, mais je suis moyen chaud pour RTFM suffisamment pour proposer des patchs Haskell, Pony ou autre Crystal.
Qui garde les gardiens
Un serveur vautré a une qualité de zéro, niveau expérience utilisateur. Il faut avoir un système pour prévenir quand ça se vautre, avec tout ce qu’il faut de contexte pour pouvoir comprendre rapidement l’incident, puis le corriger (dites bonjour à Sentry), et que ce surveillant soit lui même plus fiable que le système qu’il surveille. Pour ça, il n’y a pas 36 solutions, il faut de la redondance, et là, ça commence à gripper pour l’auto hébergement. Pour l’instant il n’y a rien comme outils simples pour avoir une coopérative de monitoring, regroupant quelques auto-hébergeur. Une fois que vous vous serez mangé un incident au moment où vous avez le plus envie de faire toute autre chose, bah, vous commencerez à vous renseigner sur la redondance et la tolérance de panne. Je ne parle pas de l’inévitable RAID de disques, mais des outils comme Consul pour coordonner une petite grappe de machines et relancer des services sur les machines survivantes, vous laissant le temps d’organiser la réparation ou le changement d’une pièce. Je parle juste de coordination de services, l’omniprésent Kubernetes est largement au-delà du scope du petit hébergement.
Efficience
Concrètement, ce qui coince, maintenant, c’est la facture énergétique, et l’utilisation du CPU. La prévisibilité de son utilisation, pour être précis.
C’est difficile de dimensionner un serveur. Techniquement le premier palier va être gros, la machine sera surdimensionnée, tout comme l’est votre poste de développement. Avec peu d’utilisateurs, si marche sur votre laptop, ça marchera sur le serveur. Par contre, avec plein d’utilisateurs, le matériel va commencer à être utilisé comme il faut. On va avoir un budget CPU/RAM/Disque par utilisateur. La notion de hit, avec les gens qui prennent le temps de lire, ça saute avec les applications et les flots HTTP. Pour avoir de la visibilité, il faut que ce budget ressource soit prévisible : si vous avez quelques workers avec 512Mo de RAM et un timeout de 30 secondes, ça va gérer les actions violentes sur le serveur, mais au détriment du nombre d’actions en parallèle. En permettant que quelques-uns puissent tout prendre, bah ça va brimer l’ensemble du groupe. Pour offrir une qualité correcte à l’ensemble, il faut des quotas raisonnables pour tous, et mettre dans des files d’attente toutes les actions gourmandes : elles seront effectuées, mais sans se marcher dessus, et en prenant le temps qu’il faut. Rigoler en voyant le load d’un serveur, ça se faisait avant l’an 2000, plus en 2020. L’asynchrone devient la règle, pour lisser les accès parallèles et assumer les différentes latences.
Simple ou simpliste, complet ou complexe ?
La tolérance du langage pour faciliter son apprentissage se paye cash au niveau maintenance et sécurité. L’analyse statique, que ce soit dans son éditeur ou la CI devient un prérequis. Typescript est venu ajouter la rigueur du typage fort à l’historiquement bordélique Javascript. Même Python a maintenant des annotations de type.
La facilité de déploiement est un argument ambigu. Pouvoir poser un machin en PHP dans un bout d’arborescence apache n’est pas un déploiement facile. Les gros mutus sont d’une autre époque, en fait. Proposer un déploiement simple sans drames de dépendances est l’objectif. La réponse ultime est bien sur le conteneur (le concept, hein, je ne parle pas d’implémentation). Les paquets systèmes ont failli pour déployer des services, mais ils gardent toute leur pertinence comme briques de base pour composer un service. La norme existe : CNAB, reste à peaufiner les implémentations.
La facilité de mises à jour avec un rollback facile est un prérequis. Si on déploie, on met à jour. Sinon, ce sera du site statique.
Visibilité
La visibilité, que ce soit les incidents ou les mesures (ce que ça fournit niveau métier, ce que ça mange), doit être systématique. htop et grep /var/log ne sont plus suffisants, hein. Sentry, même avec sa nouvelle licence est votre ami.
Arrêtez de tanner les gens avec des comptes et des mots de passe qui seront soit tout le temps le même, ou oubliées. Mozilla a lâché l’affaire avec son SSO, ce qui est frustrant, mais JWT ou OAuth sont maintenant bien diffusé. Par contre, il faut un retour en grâce d’OpenID, pour ne pas tout appuyer sur l’OAuth d’un des GAFAMs, ce qui serait un drame.
L’usine nouvelle
Arrêtez la comparaison industrie/artisanat pour l’informatique. Un service installé à la main, sur un serveur installé avec un CD, ce n’est pas comparable avec du pain ou un meuble d’artisan. La valeur de l’installation est dans la rigueur, les choix techniques, la connaissance de l’ensemble pour prendre des choix éclairés, pas dans la sueur et la vélocité des commandes tapée sur un clavier typematrix. Faites votre levain, et provisionnez vos serveurs. L’installation c’est le prélude, l’histoire, c’est la maintenance et les mises à jour de nouvelles fonctions.
Gmail n’a pas gagné par ce qu’il était meilleur, mais par ce que les offres du logiciel libre ont échoué.