L’édito de MISC n°110 !

La période de pandémie a été l’occasion pour certains de se découvrir des compétences inattendues en infectiologie et virologie, ce fut également un beau terrain de jeux pour les aspirants ingénieurs en infrastructures numériques. Nous en avons croisé beaucoup s’étranglant devant l’incapacité de l’État ou des entreprises à produire des applications tenant la charge quand il était possible, selon eux, de le faire pour une poignée d’euros avec un LAMP chez OVH.

Cette crise a été un moment de vérité cruelle pour beaucoup de briques applicatives incapables de répondre à une augmentation brutale de leur usage. Si nombre de solutions techniques semblaient parfaitement fonctionnelles il y a encore quelques mois, beaucoup d’entre elles se sont totalement écroulées lorsqu’une grande partie de la planète a dû basculer du jour au lendemain en télétravail. Car contrairement à ce que les experts autoproclamés supposent, la conception d’une application scalable est un problème complexe. Certaines problématiques de performances peuvent se traiter par de l’augmentation de mémoire, l’ajout de vCPU, de SSD supplémentaires pour multiplier les IOPS, de CDN ou encore de VM supplémentaires, mais ce n’est pas toujours possible. Ainsi, de nombreuses équipes infrastructures se sont retrouvées avec sur les bras des applications propriétaires ou open source qui fonctionnaient parfaitement depuis des années, mais étaient devenues inutilisables en quelques jours malgré un redimensionnement volontariste des ressources allouées.

Par exemple, comme les architectes applicatifs le savent, augmenter le nombre de requêtes par seconde en lecture sur un SGBD sans dégrader celles en écriture a tout de la quadrature du cercle. Et réécrire une grosse application pour la faire tourner sur une base NoSQL demande un peu de travail… Un autre cas, qui a fait la fortune de Zoom, est celui des logiciels de visioconférence qui fonctionnaient parfaitement jusqu’à une petite dizaine de personnes, mais qui se sont effondrés lorsqu’il a fallu organiser des réunions à plus de 20 personnes. Au-delà des problématiques serveur (CPU, bande passante) qui sont gérables, la difficulté est la charge sur les postes clients augmentant avec le nombre de participants dans les architectures Mesh ou SFU [1].

Un dernier point qui a été abondamment commenté est le coût de fonctionnement de l’application StopCovid [2][3]. Le chiffre jugé astronomique par une armée de bidouilleurs convaincus qu’avec un peu de tuning ils pourraient faire tourner sur un VPS à 5€/mois une application conçue pour centraliser les requêtes de quelques millions de smartphones. C’est cependant largement méconnaître le coût complet de fonctionnement d’une application quand on intègre, au-delà de la location de VM, le coût de maintien en condition opérationnelle, tout particulièrement en sous-traitance avec des SLA en 24h/24 7J/7.

Le grand public, habitué à des applications gratuites ou presque avec un très haut niveau de disponibilité, est souvent très loin d’imaginer le coût complet de conception et d’exploitation. Car si les GAFAM ont pu démontrer leur leadership en matière de fourniture de service numérique, c’est aussi parce qu’ils investissent 29 milliards de dollars par trimestre en recherche et développement [4]

[1] https://www.lemagit.fr/conseil/WebRTC-quelles-differences-entre-les-architectures-Mesh-MCU-et-SFU

[2] https://www.nouvelobs.com/economie/20200602.OBS29619/stopcovid-une-application-au-cout-sale.html

[3] https://www.lemonde.fr/pixels/article/2020/06/10/l-application-stopcovid-connait-des-debuts-decevants_6042404_4408996.html

[4] https://www.wsj.com/articles/not-even-a-pandemic-can-slow-down-the-biggest-tech-giants-11590206412

Cedric Foll / cedric@miscmag.com / @follc


Retrouvez MISC n°110 :