S’appuyer sur le matériel pour masquer les mauvaises pratiques d’ingénierie
L’ajout de matériel à un problème logiciel est une solution à court terme. Cela peut vous faire gagner du temps, mais vous ne modifiez pas le comportement réel du système, vous payez simplement pour masquer les symptômes. De nombreuses entreprises tombent dans ce travers. Des pics de latence ? Ajoutez un cache. Des goulets d’étranglement au niveau du débit ? Augmentez le nombre de serveurs. Mais les performances dépendent en fin de compte de la qualité de la conception de votre système.
De mauvaises décisions d’ingénierie au niveau du logiciel créent des inefficacités que vous ne pouvez pas éliminer éternellement. Si vos services de base ne sont pas optimisés, vos coûts continuent d’augmenter et votre architecture devient plus difficile à maintenir. L’ajout de couches masque le problème, mais le problème est toujours là, épuisant silencieusement les ressources.
Si vous financez ou dirigez une équipe de backend ou d’infrastructure, assurez-vous que les fondamentaux de l’ingénierie font partie de l’architecture. Nous parlons ici de principes de base, de structures de données respectueuses de la mémoire, d’algorithmes qui évoluent de manière prévisible. C’est ainsi que vous contrôlerez les dépenses liées au cloud, que vous réduirez l’imprévisibilité et que vous tirerez le meilleur parti du matériel que vous possédez déjà.
C’est Kelly Sommers qui l’a le mieux dit : « Les développeurs [doivent] construire des systèmes propres et faciles à maintenir qui respectent réellement le fonctionnement des ordinateurs ». Il ne s’agit pas d’écrire un code intelligent. Il s’agit de savoir ce qui fonctionne, pourquoi cela fonctionne, et de construire en gardant cela à l’esprit. Le matériel ne sauvera pas un système mal conçu. Il ne fait que repousser l’échec à plus tard, à un coût plus élevé.
Rôle fondamental des structures de données et des algorithmes dans l’efficacité du backend
Les structures de données et les algorithmes ne sont pas des théories académiques. Ce sont des leviers opérationnels. Chaque fois que vous choisissez la bonne structure pour vos données ou le bon algorithme pour votre charge de travail, vous poussez le système vers une latence plus faible, un coût plus bas et une plus grande fiabilité. Si vous n’en tenez pas compte, les coûts se traduiront par des baisses de performance, des factures de cloud plus élevées et des attentes non satisfaites de la part des clients.
Il ne s’agit pas seulement d’écrire un code rapide. Il s’agit de prendre des décisions intelligentes au niveau de l’architecture. La latence du 99e percentile, ces blips de queue qui détruisent vos accords de niveau de service, peut souvent être attribuée à des choix faibles ou paresseux dans la façon dont les données sont traitées sous la charge. Il ne s’agit pas de cas marginaux. Dans les systèmes distribués, les temps de latence sont au premier plan. Jeff Dean et Luiz André Barroso l’ont souligné dans leur étude « tail at scale » en 2013. Ce qui semble rare devient fréquent dès que vous passez à l’échelle de plusieurs services.
Si, dans votre culture d’ingénierie, les discussions sur la structure des données ne sont abordées que lors d’entretiens, vous avez mal aligné vos priorités. Ces décisions ont un impact direct sur vos objectifs de niveau de service (SLO) et votre coût des marchandises vendues (COGS). Pensez aux structures de données et aux algorithmes de la même manière que votre équipe financière pense au retour sur investissement. Vous ne pouvez pas vous permettre de traiter l’ingénierie fondamentale comme une option.
Le leadership commence par fixer la barre. Donnez la priorité aux principes fondamentaux. Assurez-vous que vos équipes comprennent les implications de leurs choix de conception en termes de performances. Le résultat est simple : des systèmes plus rapides, des coûts moins élevés et moins de surprises en cas d’augmentation de la demande. Cela se répercute sur l’ingénierie, les produits et les finances.
La prise en compte du matériel dans la conception des logiciels est cruciale pour les performances
La plupart des ralentissements de systèmes commencent par une mauvaise compréhension du fonctionnement des ordinateurs. Il ne s’agit pas seulement d’écrire un code qui fonctionne, il s’agit d’écrire un code que le matériel peut exécuter efficacement. Si vous ne tenez pas compte de la mise en cache, de la disposition de la mémoire ou de la manière dont vos données se déplacent dans le système, vous vous retrouvez avec des unités centrales qui restent inactives, des réseaux encombrés et des performances qui s’effondrent sous la pression.
L’écart entre un accès au cache L1 et un accès à la mémoire principale est énorme. Il s’agit de centaines de cycles. Un voyage à travers un centre de données ? Des ordres de grandeur plus lents. Il ne s’agit pas de cas marginaux, mais de réalités fondamentales auxquelles les ingénieurs sont confrontés à grande échelle. Vous pouvez faire en sorte que l’algorithme ait l’air propre sur le papier, mais s’il ne s’aligne pas sur la hiérarchie de la mémoire ou s’il perturbe la localité de la mémoire cache, il s’effondre sous la charge.
L’article d’Ulrich Drepper publié en 2007 l’a clairement mis en évidence. Un code qui devrait se comporter de manière linéaire peut se dégrader de manière spectaculaire s’il commence à s’attaquer aux caches ou à franchir les limites de la NUMA (Non-Uniform Memory Access). Si vous n’êtes pas attentif aux schémas d’accès à la mémoire, vous perdez des performances pour lesquelles vous avez déjà payé.
La conclusion est simple : une conception adaptée au matériel vous permet d’obtenir un effet de levier. Les structures de données adaptées au cache, telles que les dispositions SoA ou les implémentations B-tree étroites, transforment les temps morts de l’unité centrale en débit. Et ce débit n’est pas théorique. C’est ce qui détermine si votre système gère avec confiance un trafic utilisateur élevé ou s’il s’effondre sous la pression. Investissez dans des équipes qui ne se contentent pas d’écrire du code correct, mais qui écrivent du code qui respecte les machines qui l’exécutent.
La conception du moteur de stockage met en évidence les compromis dans le choix des structures de données
Le stockage n’est pas seulement une couche passive, c’est l’endroit où la conception de votre système devient réelle. Chaque requête, chaque écriture, chaque lecture se heurte à une structure que votre équipe a choisie ou dont elle a hérité. Et chacune de ces structures, qu’il s’agisse d’un arbre B+ ou d’un arbre LSM, s’accompagne de compromis qui déterminent le coût, la latence et l’évolutivité.
Si vous êtes sensible à la latence de lecture et que vous exécutez des requêtes de plage, les arbres B+ offrent des modèles d’accès serrés et alignés sur le cache qui donnent de bons résultats. Mais les charges de travail à forte intensité d’écriture bénéficient souvent des arbres LSM, qui mettent en mémoire tampon les écritures avant de les fusionner en lots plus importants, optimisant ainsi le débit. Cela semble intéressant, mais les arbres LSM ont des effets secondaires, comme l’amplification de la lecture et le compactage en arrière-plan, qui consomment des cycles de l’unité centrale.
Il ne s’agit pas de détails mineurs. Ils influencent tout, de l’usure des disques SSD au montant que vous dépensez pour les IOPS. Plus important encore, ils déterminent si vous investissez dans une infrastructure qui vous rapproche ou vous éloigne de vos objectifs commerciaux.
Ces décisions ne concernent pas seulement les ingénieurs. Ce sont des leviers financiers. Lorsque vous financez une plateforme, vous financez les résultats de ces choix. Aidez vos équipes à définir ces options en fonction des charges de travail réelles et tenez l’architecture pour responsable. C’est ainsi que vous obtiendrez des systèmes évolutifs tant sur le plan technique qu’économique.
Des algorithmes de qualité supérieure peuvent surpasser les systèmes parallèles à grande échelle
La plupart du temps, ce n’est pas l’échelle qui pose problème, mais l’inefficacité. Trop de systèmes s’engagent de manière excessive dans le parallélisme sans faire le travail nécessaire pour que les performances d’un seul thread soient prises en compte. Le résultat est prévisible : plus de machines, plus de puissance, plus de coûts. Mais avec la bonne conception algorithmique, un système à un seul fil peut surpasser les clusters parallèles massifs.
Frank McSherry, Michael Isard et Derek Murray ont fait les comptes. Leur recherche a introduit la métrique COST (Configuration that Outperforms a Single Thread). Ils ont découvert que de nombreux systèmes « évolutifs » nécessitaient des centaines de cœurs pour obtenir le même résultat qu’avec un seul thread bien implémenté. Cette constatation devrait alerter tous ceux qui financent d’importants investissements d’infrastructure.
En termes pratiques, si vous pouvez résoudre un problème de performance avec un meilleur logiciel plutôt qu’avec plus de matériel, vous économisez de l’argent, réduisez les temps de latence et simplifiez les opérations. Les équipes d’ingénieurs optent souvent pour des systèmes distribués sans se demander au préalable si la charge de travail ne pourrait pas être gérée plus proprement grâce à une conception plus intelligente. C’est une erreur.
Les dirigeants doivent donner la priorité aux investissements qui évoluent intelligemment. Avant d’acheter plus de capacité de calcul, demandez-vous si le logiciel que vous utilisez est efficace. Si ce n’est pas le cas, vous brûlez des ressources pour masquer un défaut de conception. De meilleurs algorithmes s’adaptent mieux, non seulement aux machines, mais aussi au temps et aux cycles économiques. Un logiciel intelligent aujourd’hui permet d’économiser des millions plus tard.
Les sélections stratégiques d’algorithmes permettent d’obtenir des avantages en termes de coûts et de performances
Des choix clairs dans la conception des algorithmes ne sont pas des exercices théoriques, ils génèrent une valeur commerciale mesurable. Facebook est passé de zlib à Zstandard (zstd) pour la compression. Non pas parce qu’il était à la mode, mais parce qu’il offrait de meilleurs taux de compression et des vitesses de (dé)compression plus rapides. Cela a permis d’améliorer les performances de bout en bout tout en réduisant les coûts de stockage et de sortie dans l’ensemble de l’infrastructure.
C’est ce qui se passe lorsque les principes de l’ingénierie soutiennent la croissance de l’entreprise. Choisir le bon algorithme de compression n’est pas seulement une victoire technique, c’est aussi une victoire financière. Chaque amélioration en amont de la taille et de la vitesse réduit la charge du serveur, l’accès à la mémoire, l’utilisation de la bande passante et le temps d’attente de l’utilisateur. Il ne s’agit pas de gains abstraits. Ils sont visibles sur votre facture de cloud et sur les tableaux de bord de vos produits.
Le même principe s’applique partout : choisissez l’option la plus rapide et la plus efficace qui fonctionne à grande échelle et maintenez-la délibérément. Ne vous contentez pas des valeurs par défaut. Examinez les algorithmes qui sous-tendent vos services et remettez en question les hypothèses. C’est là que se trouve la marge, cachée dans les décisions que la plupart des gens ne revoient jamais.
Les chefs d’entreprise se demandent souvent où mettre le prochain dollar. Voici une réponse : des incitations qui poussent les équipes à auditer leurs bases techniques et à remplacer les choix vieillissants par de meilleurs choix. Lorsque la dette technique est réduite grâce à des algorithmes intelligents, l’organisation gagne en rapidité et en maîtrise des coûts. C’est ce résultat qui compte.
Une architecture de données solide est encore plus essentielle dans les systèmes pilotés par l’IA
Dans les systèmes d’IA, la performance n’est pas seulement déterminée par la puissance de votre GPU ou la complexité de votre modèle. Une grande partie des gains, ou des pertes, provient de la manière dont vos données sont acheminées dans le pipeline. C’est pourquoi les choix fondamentaux concernant les structures de données sont plus importants dans le domaine de l’IA que partout ailleurs. Une mauvaise architecture multiplie les inefficacités. Les bons principes fondamentaux multiplient les avantages.
Les pipelines d’apprentissage automatique reposent sur des composants tels que les formats en colonnes, les index vectoriels et le traitement par lots. Il ne s’agit pas d’espaces réservés. Ils définissent la latence, le débit et la réactivité du modèle. Si un travail ETL est lent à cause de jointures mal dimensionnées ou si la latence d’extraction augmente à cause de magasins vectoriels inefficaces, l’ajout de calcul ne résoudra pas le problème. Cela ne fera que dissimuler l’inefficacité pendant un certain temps.
De nombreux systèmes d’IA tombent en panne non pas parce que l’apprentissage est difficile, mais parce que l’infrastructure soutenant le flux de données a été mal planifiée. Les frais généraux de sérialisation, la logique de jointure confuse ou l’absence de stratégie de mise en cache nuisent à la livraison des modèles plus que leur taille. Même les chemins d’inférence souffrent lorsque la majeure partie du temps est perdue à déplacer des données de manière inefficace à travers les couches du système.
Pour les dirigeants, voici le message clé : Le succès de l’IA dépend de la capacité des équipes d’ingénieurs à poser les bonnes bases. Cela signifie qu’il faut sélectionner des structures de données rapides et évolutives, utiliser des formats qui bénéficient de l’alignement du matériel et supprimer les goulets d’étranglement avant de déployer des correctifs. La complexité ne justifie pas l’inefficacité. Dans le domaine de l’IA, ce sont les fondamentaux qui permettent d’augmenter la valeur, et pas seulement les pipelines.
L’intégration des principes fondamentaux dans la culture de conception garantit la prévisibilité et la maîtrise des coûts.
Les performances ne sont pas censées être accidentelles. Et si vos systèmes n’atteignent leurs objectifs de performance que lorsqu’un spécialiste arrive tard dans la nuit pour réparer quelque chose, vous n’avez pas un système solide, mais instable. Les systèmes conçus en gardant à l’esprit les principes fondamentaux, les structures de données étroites, les agencements intelligents, la transparence des compromis, ne devinent pas leur succès. Ils agissent de manière prévisible, sous charge et au fil du temps.
Lorsque les revues de conception incluent des conversations explicites sur la disposition des données, l’impact sur la mémoire et le coût algorithmique, les équipes se transforment en constructeurs de systèmes fiables. Elles savent pourquoi leurs systèmes se comportent d’une certaine manière. Elles n’ont pas recours à l’optimisation en dernier ressort, mais intègrent les performances dès le départ. Cela crée une prévisibilité au niveau des opérations, de la gestion des coûts et de l’expérience des utilisateurs.
Kelly Sommers l’exprime bien lorsqu’elle dit : « Parfois, la meilleure architecture ne consiste pas à avoir raison, mais à glisser de bons principes fondamentaux dans le cadre que votre équipe aime déjà ». En d’autres termes, rencontrez les équipes là où elles sont, mais ne faites pas de compromis sur la clarté de l’ingénierie. Les dirigeants doivent aider les équipes à intégrer les principes fondamentaux dans chaque couche de l’architecture du système, sans se dérober ni prendre de raccourcis.
La prévisibilité est un levier. C’est ainsi que vous conservez la confiance des utilisateurs, que vous atteignez les objectifs de niveau de service en utilisant la capacité dont vous disposez déjà et que vous prévoyez les coûts d’infrastructure avec précision. Ce n’est pas de l’idéalisme. Il s’agit d’un changement mesurable dans la manière dont les systèmes réagissent à la croissance. Lorsque chaque ingénieur comprend pourquoi le système utilise ce qu’il utilise et comment ces décisions affectent les performances, vous finissez par dépenser moins pour faire plus.
Le succès à long terme repose sur la rigueur algorithmique et non sur des correctifs d’infrastructure temporaires.
Le fait de compter sur l’infrastructure pour couvrir l’inefficacité des logiciels crée des systèmes coûteux à mettre à l’échelle et auxquels il est difficile de faire confiance. Des serveurs supplémentaires, plus de mémoire ou des IOPS plus élevés peuvent aider à masquer le problème à court terme, mais l’inefficacité principale demeure. La stabilité à long terme et les performances financières découlent de la clarté des algorithmes, et non de la mise à l’échelle d’une mauvaise conception.
Les systèmes qui reposent sur des choix judicieux en matière d’algorithmes et de structures de données offrent des performances constantes, même lorsque la demande augmente. Ils sont plus rentables, plus faciles à entretenir et moins susceptibles de tomber en panne sous la pression. Ce type de fiabilité n’est pas le fruit du hasard. Elle est le fait d’équipes qui accordent la priorité aux principes fondamentaux et qui les révisent en permanence.
Pour les dirigeants, il ne s’agit pas seulement d’une déclaration technique, mais d’une directive commerciale. Les systèmes conçus sur de mauvaises bases nécessiteront plus de budget, plus d’intervention, plus de soutien. Cela réduit les marges et conduit à des résultats imprévisibles. Mais lorsque les principes fondamentaux guident les décisions d’ingénierie, chaque amélioration s’additionne : exécutions plus rapides, factures de cloud moins élevées et moins d’escalades d’urgence.
Vous n’avez pas besoin d’attendre l’effondrement du système pour donner la priorité aux principes fondamentaux. Commencez à les intégrer dans la planification de l’architecture, l’évaluation des performances et les normes d’embauche. Intégrez-les au modèle d’exploitation. Ce changement est payant, non seulement en termes de résultats techniques, mais aussi en termes de clarté financière et de confiance des clients.
Au fil du temps, les systèmes bien structurés augmentent la vélocité de l’organisation. Ils réduisent la fréquence des incidents. Ils créent une marge de manœuvre pour la croissance au lieu de poursuivre constamment des objectifs de performance. C’est ainsi que vous atteignez des objectifs à long terme, avec des systèmes construits sur des principes qui ne se dégradent pas sous la charge.
Récapitulation
Les décisions techniques sont des décisions commerciales. Si vos systèmes ne fonctionnent qu’en ajoutant du matériel au problème, le vrai problème n’est pas l’infrastructure, mais la façon dont votre logiciel est construit. C’est ce qui ressort de votre facture de cloud, de vos échecs en matière de SLO et des cycles de lutte contre l’incendie de votre équipe.
Les entreprises intelligentes investissent dans les fondamentaux. Elles respectent le fonctionnement des ordinateurs. Elles construisent des systèmes prévisibles, efficaces et conscients des coûts. Les structures de données, les schémas d’accès à la mémoire et les compromis algorithmiques ne sont pas des préoccupations secondaires. Ils définissent votre capacité à évoluer durablement et à être compétitif.
En tant que responsable, votre rôle est de veiller à ce que ces principes soient intégrés dans la manière dont vos équipes conçoivent, examinent et exploitent les logiciels. Abandonnez la croissance réactive. Faites pression pour que les choix techniques soient clairs et que les résultats soient mesurables. Vous n’avez pas besoin de plus de serveurs, vous avez besoin d’une meilleure ingénierie. C’est là que réside la valeur composée.
