Comment la componentisation des applications impacte les performances et la sécurité
Autrefois, les entreprises pouvaient compter sur l’utilisation de proxys déployés de manière stratégique pour améliorer les performances des applications. C'est parce que les applications traditionnelles (monolithes et architectures à trois niveaux) utilisent généralement un seul chemin des données entre le client et le serveur.
En termes simples, il n'y avait qu'un seul chemin emprunté pour tout le contenu, qu'il soit statique ou dynamique, basé sur du texte ou des images. Cela signifiait qu'un contrôleur de distribution application (proxy) pouvait se placer entre eux et, avec le bon, optimiser les performances. Cela était - et est toujours, d'ailleurs - souvent réalisé grâce au réglage de divers boutons et boutons IP, TCP et même HTTP. Nous pouvons voir l’utilisation de ces types de techniques à travers le déploiement de services application tels que la mise en cache, la compression et les techniques d’accélération spécifiques au contenu.
Mais les applications modernes ne sont plus autonomes. Ils sont désormais, selon Sonatype , majoritairement constitués (80 à 90 %) de composants tiers (et de plus en plus open source). Vous le constatez dans le nombre de scripts et autres codes injectables présents dans les applications Web. Parfois, ce script s'exécute à distance et renvoie une image, une publicité ou un autre contenu tel que des polices Web et des sprites. D'autres fois, le script lui-même est chargé au moment de l'exécution et s'exécute dans les limites du navigateur, comme jQuery.
C'est ce qu'on appelle la componentisation - ou l'atomisation, si vous préférez. Il s’agit de décomposer les applications en plusieurs parties plus petites. Nous les appelons composants côté client, car ils s'exécutent généralement dans le même espace. Côté serveur, nous les appelons de plus en plus microservices et les déployons dans des conteneurs. Dans les deux cas, l’impact est similaire : nous nous retrouvons avec un nombre imprévisible de chemins de données qui ont un impact direct sur les performances.
Fondamentalement, vous avez le contrôle sur un chemin des données , qui représente peut-être 20 % de votre application. Cela signifie que vous avez très peu de contrôle sur l’expérience utilisateur, car vous avez très peu de contrôle sur les performances.
C'est également vrai pour la sécurité - merci de l'avoir remarqué. Le fait est que nous apprenons rapidement à tirer parti des techniques de code côté client pour améliorer la sécurité. Cela ne fonctionne pas aussi bien avec les performances, car la plupart des applications sont soit mobiles, soit Web, et aucune des deux n'offre vraiment la possibilité ou la capacité de jouer avec la pile réseau.
L’une des façons de lutter contre ce problème est de reprendre le contrôle. L’avantage de reprendre le contrôle est que vous pouvez également bénéficier des effets secondaires en matière de sécurité.
Gagnant-gagnant : RÉDUIRE LES RISQUES ET AMÉLIORER LES PERFORMANCES
Si vos applications ont l’habitude de charger dynamiquement des composants à partir de sites externes, arrêtez-le. Arrête ça maintenant. Il s’agit autant d’un problème de sécurité que de performances. Vous donnez implicitement carte blanche à un script provenant d'une source externe pour qu'il s'exécute dans le contexte de votre application. Croyez-moi, un utilisateur ne pourra pas faire la distinction entre vos composants et ceux chargés en externe en cas de faille de sécurité. Comme nous l’avons appris lors de la récente crise liée à la vulnérabilité du conteneur runc , l’injection de code malveillant dans des ressources chargées à partir de registres ou de sites tiers comporte un risque de sécurité.
S'il s'agit d'un script, il est préférable de le cloner et de le diffuser à partir de votre propre infrastructure. Vous bénéficierez d'une réduction des risques en gardant le contrôle et en étant capable de modifier les boutons et les commandes qui améliorent les performances pour vos utilisateurs. Cela inclut le DNS, dont il a été constamment démontré qu’il avait le plus grand impact (souvent négatif) sur les performances des application . Lorsque vous extrayez des composants de sites externes, vous comptez sur leur infrastructure DNS pour fonctionner à la hauteur de vos attentes. L'extraction de composants à partir de vos propres sites peut réduire considérablement l'impact simplement parce que le cache DNS local de l'utilisateur fonctionne pour vous.
L'hébergement de scripts à partir de votre propre site vous permet également d'utiliser des optimisations TCP ou des techniques de déchargement SSL/TLS ou d'accélération générale des applications pour améliorer les performances globales. Cela offre également la possibilité d'effectuer des analyses de sécurité sur ces scripts pour garantir qu'aucune surprise ne se cache au plus profond d'eux-mêmes.
La componentisation est idéale pour le développement et contribue certainement à accélérer le délai de rentabilisation. Mais cela peut avoir un impact négatif sur les performances – et la sécurité. Soyez conscient des risques liés à la sécurité et à la satisfaction des utilisateurs et de ce que vous pouvez faire pour les combattre.