Qu'est-ce que l'évolutivité logicielle et pourquoi votre entreprise devrait-elle la prendre au sérieux ?

Même les entreprises expérimentées et prospères peuvent avoir des problèmes d'évolutivité. Vous souvenez-vous de l'application Applause de Disney ? Il a permis aux utilisateurs d'interagir avec différents spectacles Disney. Lorsque l'application est apparue sur Google Play, elle était extrêmement populaire. Pas si évolutif, cependant. Il ne pouvait pas gérer un grand nombre de fans, ce qui entraînait une mauvaise expérience utilisateur. Les gens étaient furieux, laissant des commentaires négatifs et une note d'une étoile sur Google Play. L'application ne s'est jamais remise de cette publicité négative.

Vous pouvez éviter de tels problèmes si vous prêtez attention à l'évolutivité du logiciel au cours des premières étapes du développement, que vous l'implémentiez vous-même ou que vous utilisiez des services d'ingénierie logicielle.

Alors, qu'est-ce que l'évolutivité dans les logiciels ? Comment s'assurer que votre solution est évolutive ? Et quand devez-vous commencer à évoluer ?

Qu'est-ce que l'évolutivité logicielle ?

Gartner définit l'évolutivité comme la mesure de la capacité d'un système à diminuer ou à augmenter ses performances et ses coûts en réponse aux modifications des demandes de traitement.

Dans le contexte du développement de logiciels, l'évolutivité est la capacité d'une application à gérer les variations de la charge de travail tout en ajoutant ou en supprimant des utilisateurs à moindre coût. Ainsi, une solution évolutive devrait rester stable et maintenir ses performances après une forte augmentation de la charge de travail, qu'elle soit attendue ou spontanée. Voici des exemples d'augmentation de la charge de travail :

• De nombreux utilisateurs accédant au système simultanément
• Augmentation des besoins en capacité de stockage
• Augmentation du nombre de transactions en cours de traitement

Types d'évolutivité logicielle

Vous pouvez redimensionner une application horizontalement ou verticalement. Voyons quels sont les avantages et les inconvénients de chaque approche.

Évolutivité horizontale du logiciel (scaling out)

Vous pouvez faire évoluer le logiciel horizontalement en incorporant des nœuds supplémentaires dans le système pour gérer une charge plus élevée, car elle sera répartie sur les machines. Par exemple, si une application commence à subir des retards, vous pouvez évoluer en ajoutant un autre serveur.

L'évolutivité horizontale est un meilleur choix lorsque vous ne pouvez pas estimer la charge que votre application devra gérer à l'avenir. C'est également une option incontournable pour les logiciels qui doivent évoluer rapidement sans temps d'arrêt.

Avantages:

• Résilience à l'échec. Si un nœud tombe en panne, les autres prendront le relais
• Il n'y a pas de temps d'arrêt pendant la mise à l'échelle car il n'est pas nécessaire de désactiver les nœuds existants lors de l'ajout de nouveaux
• Théoriquement, les possibilités de mise à l'échelle horizontale sont illimitées

Limites:

• Complexité ajoutée. Vous devez déterminer comment la charge de travail est répartie entre les nœuds. Vous pouvez utiliser Kubernetes pour la gestion de la charge
• Coûts plus élevés. L'ajout de nouveaux nœuds coûte plus cher que la mise à niveau des nœuds existants
• La vitesse globale du logiciel peut être limitée par la vitesse de communication des nœuds

Évolutivité logicielle verticale (mise à l'échelle)

L'évolutivité verticale consiste à ajouter plus de puissance au matériel existant. Si, avec l'évolutivité horizontale, vous souhaitez ajouter un autre serveur pour gérer la charge d'une application, ici, vous mettrez à jour le serveur existant en ajoutant plus de puissance de traitement, de mémoire, etc. Une autre option consiste à supprimer l'ancien serveur et à en connecter un plus avancé et plus performant à la place.

Ce type d'évolutivité fonctionne bien lorsque vous connaissez la quantité de charge supplémentaire que vous devez intégrer.

Avantages:

• Il n'est pas nécessaire de modifier la configuration ou la logique d'une application pour s'adapter à l'infrastructure mise à jour
• Réduction des dépenses, car il coûte moins cher de mettre à niveau que d'ajouter une autre machine

Limites:

• Il y a un temps d'arrêt pendant le processus de mise à niveau
• La machine mise à niveau présente toujours un seul point de défaillance
• Il y a une limite sur combien vous pouvez mettre à niveau un appareil

Évolutivité verticale ou horizontale du logiciel

Voici un tableau comparatif qui donne un aperçu des différents aspects des deux types d'évolutivité logicielle.

Quand avez-vous absolument besoin d'évolutivité ?

De nombreuses entreprises délaissent l'évolutivité dans l'ingénierie logicielle au profit de coûts réduits et de cycles de vie de développement de logiciels plus courts. Et même s'il existe quelques cas où l'évolutivité n'est pas un attribut essentiel de la qualité du système, dans la plupart des situations, vous devez en tenir compte dès les premières étapes du cycle de vie de votre produit.

Lorsque l'évolutivité logicielle n'est pas nécessaire :

• Si le logiciel est une preuve de concept (PoC) ou un prototype
• Lors du développement de logiciels internes pour les petites entreprises utilisés uniquement par les employés
• Application mobile/de bureau sans back-end

Pour le reste, il est fortement recommandé de se pencher sur les options d'évolutivité pour être prêt le moment venu. Et comment savez-vous qu'il est temps de passer à l'échelle ? Lorsque vous remarquez une dégradation des performances. Voici quelques indications :

• Le temps de réponse des applications augmente
• Incapacité à gérer les demandes simultanées des utilisateurs
• Augmentation des taux d'erreur, tels que les échecs de connexion et les délais d'attente
• Des goulots d'étranglement se forment fréquemment. Vous ne pouvez pas accéder à la base de données, l'authentification échoue, etc.

Conseils pour créer un logiciel hautement évolutif

L'évolutivité logicielle est beaucoup moins chère et plus facile à mettre en œuvre si elle est envisagée au tout début du développement logiciel. Si vous devez évoluer de manière inattendue sans prendre les mesures nécessaires lors de la mise en œuvre, le processus consommera beaucoup plus de temps et de ressources. Une de ces approches consiste à refactoriser le code, ce qui est un effort en double, car il n'ajoute aucune nouvelle fonctionnalité. Il fait simplement ce qui aurait dû être fait pendant le développement.

Vous trouverez ci-dessous huit conseils qui vous aideront à créer des logiciels plus faciles à mettre à l'échelle à l'avenir. Le tableau ci-dessous divise les astuces en différentes étapes de développement logiciel.

Conseil n°1 : optez pour l'hébergement dans le cloud pour une meilleure évolutivité du logiciel

Vous avez deux options pour héberger vos applications, soit dans le cloud, soit sur site. Ou vous pouvez utiliser une approche hybride.

Si vous optez pour le modèle sur site , vous comptez sur votre propre infrastructure pour exécuter des applications, héberger votre stockage de données, etc. Cette configuration limitera votre capacité à évoluer et la rendra plus coûteuse. Cependant, si vous opérez dans un secteur fortement réglementé, vous n'aurez peut-être pas le choix, car l'hébergement sur site vous donne plus de contrôle sur les données.

De plus, dans certains secteurs, tels que la banque, le temps de traitement des transactions est essentiel et vous ne pouvez pas vous permettre d'attendre que le cloud réponde ou de tolérer tout temps d'arrêt des fournisseurs de cloud. Les entreprises opérant dans ces secteurs sont limitées à l'utilisation de matériel spécifique et ne peuvent pas compter sur l'offre des fournisseurs de cloud. Il en va de même pour les applications urgentes et critiques, comme les véhicules automatisés.

Choisir des services de cloud computing vous donnera la possibilité d'accéder à des ressources tierces au lieu d'utiliser votre infrastructure. Avec le cloud, vous avez une possibilité presque illimitée d'évoluer vers le haut et vers le bas sans avoir à investir dans des serveurs et d'autres matériels. Les fournisseurs de cloud sont également responsables de la maintenance et de la sécurisation de l'infrastructure.

Si vous travaillez dans le secteur de la santé, vous pouvez consulter notre article sur le cloud computing dans le secteur médical.

Conseil n° 2 : utilisez l'équilibrage de charge

Si vous décidez d'évoluer horizontalement, vous devrez déployer un logiciel d'équilibrage de charge pour répartir les requêtes entrantes entre tous les appareils capables de les gérer et vous assurer qu'aucun serveur n'est submergé. Si un serveur tombe en panne, un équilibreur de charge redirigera le trafic du serveur vers d'autres machines en ligne capables de gérer ces demandes.

Lorsqu'un nouveau nœud est connecté, il fera automatiquement partie de la configuration et commencera également à recevoir des demandes.

Conseil n° 3 : Cachez autant que vous le pouvez

Le cache est utilisé pour stocker le contenu statique et les résultats précalculés auxquels les utilisateurs peuvent accéder sans avoir à refaire les calculs.

Mettez en cache autant de données que possible pour alléger la charge de votre base de données. Configurez votre logique de traitement de manière à ce que les données rarement modifiées mais lues assez souvent puissent être récupérées à partir d'un cache distribué. Ce sera plus rapide et moins coûteux que d'interroger la base de données à chaque requête simple. De plus, lorsqu'un élément n'est pas dans le cache mais est souvent consulté, votre application le récupère et met en cache les résultats.

Cela pose des problèmes, tels que la fréquence d'invalidation du cache, le nombre de fois où une donnée doit être accessible pour être copiée dans le cache, etc.

Conseil n° 4 : Activez l'accès via les API

Les utilisateurs finaux accéderont à votre logiciel via une variété de clients, et il sera plus pratique d'offrir une interface de programmation d'application (API) que tout le monde pourra utiliser pour se connecter. Une API est comme un intermédiaire qui permet à deux applications de se parler. Assurez-vous de tenir compte des différents types de clients, y compris les smartphones, les applications de bureau, etc.

Gardez à l'esprit que les API peuvent vous exposer à des failles de sécurité. Essayez de résoudre ce problème avant qu'il ne soit trop tard. Vous pouvez utiliser des passerelles sécurisées, une authentification forte, des méthodes de cryptage, etc.

Conseil n° 5 : Bénéficiez du traitement asynchrone

Un processus asynchrone est un processus qui peut exécuter des tâches en arrière-plan. Le client n'a pas besoin d'attendre les résultats et peut commencer à travailler sur autre chose. Cette technique permet l'évolutivité du logiciel car elle permet aux applications d'exécuter plus de threads, permettant aux nœuds d'être plus évolutifs et de gérer plus de charge. Et si une tâche chronophage arrive, elle ne bloquera pas la menace d'exécution et l'application pourra toujours gérer d'autres tâches simultanément.

Le traitement asynchrone consiste également à répartir les processus en étapes lorsqu'il n'est pas nécessaire d'attendre qu'une étape soit terminée pour commencer la suivante si cela n'est pas critique pour le système. Cette configuration permet de répartir un processus sur plusieurs threads d'exécution, ce qui facilite également l'évolutivité.

Le traitement asynchrone est réalisé au niveau du code et de l'infrastructure, tandis que la gestion des demandes asynchrones est au niveau du code.

Conseil n° 6 : optez pour des types de bases de données plus faciles à mettre à l'échelle, lorsque cela est possible

Certaines bases de données sont plus faciles à mettre à l'échelle que d'autres. Par exemple, les bases de données NoSQL, telles que MongoDB, sont plus évolutives que SQL. Le MongoDB susmentionné est open source et est généralement utilisé pour l'analyse de données volumineuses en temps réel. Les autres options NoSQL sont Amazon DynamoDB et Google Bigtable.

SQL fonctionne bien lorsqu'il s'agit de mettre à l'échelle les opérations de lecture, mais il se bloque sur les opérations d'écriture en raison de sa conformité aux principes ACID (atomicité, cohérence, isolation et durabilité). Donc, si ces principes ne sont pas la principale préoccupation, vous pouvez opter pour NoSQL pour une mise à l'échelle plus facile. Si vous avez besoin de vous appuyer sur des bases de données relationnelles, pour des raisons de cohérence ou pour toute autre question, il est toujours possible d'évoluer à l'aide du sharding et d'autres techniques.

Conseil n° 7 : choisissez les microservices plutôt que l'architecture monolithique, le cas échéant

Architecture monolithique

Un logiciel monolithique est construit comme une seule unité combinant des opérations côté client et côté serveur, une base de données, etc. Tout est étroitement couplé et a une base de code unique pour toutes ses fonctionnalités. Vous ne pouvez pas simplement mettre à jour une partie sans affecter le reste de l'application.

Il est possible de mettre à l'échelle un logiciel monolithique, mais il doit être mis à l'échelle de manière holistique en utilisant l'approche de mise à l'échelle verticale, qui est coûteuse et inefficace. Si vous souhaitez mettre à niveau une partie spécifique, il n'y a pas d'échappatoire à la reconstruction et au redéploiement de l'application entière. Alors, optez pour un monolithique si votre solution n'est pas complexe et ne sera utilisée que par un nombre limité de personnes.

Architecture de microservices

Les microservices sont plus flexibles que les monolithes. Les applications conçues dans ce style se composent de nombreux composants qui fonctionnent ensemble mais sont déployés indépendamment. Chaque composant offre une fonctionnalité spécifique. Les services constituant une application peuvent avoir différentes piles technologiques et accéder à différentes bases de données. Par exemple, une application de commerce électronique conçue en tant que microservices aura un service pour la recherche de produits, un autre pour les profils d'utilisateurs, un autre encore pour la gestion des commandes, etc.

Les composants d'application de microservice peuvent être mis à l'échelle indépendamment sans surcharger l'ensemble du logiciel. Donc, si vous recherchez une solution évolutive, les microservices sont votre conception de choix. L'évolutivité logicielle élevée n'est que l'un des nombreux avantages que vous pouvez tirer de cette architecture. Pour plus d'informations, consultez notre article sur les avantages des microservices.

Conseil n° 8 : surveillez les performances pour déterminer quand procéder à une mise à l'échelle

Après le déploiement, vous pouvez surveiller votre logiciel pour détecter les premiers signes de dégradation des performances qui peuvent être résolus par une mise à l'échelle. Cela vous donne l'occasion de réagir avant que le problème ne s'aggrave. Par exemple, lorsque vous remarquez que la mémoire est insuffisante ou que les messages attendent d'être traités plus longtemps que la limite spécifiée, cela indique que votre logiciel fonctionne à sa capacité.

Pour être en mesure d'identifier ces problèmes et d'autres liés à l'évolutivité logicielle, vous devez intégrer un système de surveillance de télémétrie dans votre application pendant la phase de codage. Ce système vous permettra de suivre :

• Temps de réponse moyen
• Le débit, qui est le nombre de requêtes traitées à un moment donné
• Le nombre d'utilisateurs simultanés
• Mesures de performances de la base de données, telles que le temps de réponse aux requêtes
• Utilisation des ressources, telles que CPU, utilisation de la mémoire, GPU
• Taux d'erreur
• Coût par utilisateur

Vous pouvez bénéficier des solutions de surveillance et des cadres d'agrégation de journaux existants, tels que Splunk. Si votre logiciel s'exécute dans le cloud, vous pouvez utiliser la solution du fournisseur de cloud. Par exemple, Amazon propose AWS CloudWatch à cet effet.

Exemples de solutions logicielles évolutives du portefeuille ITRex

Miroir de fitness intelligent avec coach personnel

Description du projet

Le client souhaitait construire un miroir de fitness mural sur toute la longueur qui aiderait les utilisateurs dans leur routine d'entraînement. Il pourrait surveiller la forme de l'utilisateur pendant l'exercice, compter les répétitions, etc. Ce système était censé inclure un logiciel permettant aux entraîneurs de créer et de télécharger des vidéos, et aux utilisateurs d'enregistrer et de gérer leurs entraînements.

Ce que nous avons fait pour assurer l'évolutivité du logiciel

• Nous avons opté pour une architecture de microservices
• Évolutivité horizontale mise en œuvre pour la répartition de la charge. Un nouveau nœud a été ajouté chaque fois qu'il y avait trop de charge sur les nœuds existants. Ainsi, chaque fois que l'utilisation du processeur dépassait 90 % de sa capacité et y restait pendant une période de temps spécifiée, un nouveau nœud était ajouté pour alléger la charge.
• Nous avons dû déployer des bases de données relationnelles, c'est-à-dire SQL et PostgreSQL, pour des raisons architecturales. Même si les bases de données relationnelles sont plus difficiles à mettre à l'échelle, il existe encore plusieurs options. Au début, comme la base d'utilisateurs était encore relativement petite, nous avons opté pour une mise à l'échelle verticale. Si l'audience augmentait, nous prévoyions de déployer l'approche maître-esclave, c'est-à-dire de répartir les données sur plusieurs bases de données.
• Largement bénéficié de la mise en cache car ce système contient de nombreuses informations statiques, telles que les noms des entraîneurs, les titres des entraînements, etc.
• Utilisation de RestAPI pour le traitement asynchrone des requêtes entre l'application d'entraînement et le serveur
• S'appuie sur une architecture sans serveur, telle qu'AWS Lambda, pour d'autres types de traitement asynchrone. Un exemple est le traitement vidéo asynchrone. Une fois qu'un entraîneur a chargé une nouvelle vidéo d'entraînement et l'a segmentée en différents exercices, il appuie sur "enregistrer" et le serveur commence à traiter cette vidéo pour la diffusion en direct HTTP afin de créer quatre versions de la vidéo originale avec différentes résolutions. Le formateur peut télécharger simultanément de nouvelles vidéos.
• Dans un autre exemple, le système effectue de manière asynchrone un découpage intelligent sur les vidéos des utilisateurs pour supprimer toutes les parties où l'utilisateur était inactif.

Système de cybersécurité basé sur la biométrie

Description du projet

Le client souhaitait créer une plate-forme de cybersécurité permettant aux entreprises d'authentifier les employés, les sous-traitants et les autres utilisateurs sur la base de la biométrie, et d'éviter les mots de passe et les codes PIN. Cette plate-forme contiendrait également un outil vidéo en direct pour confirmer à distance l'identité de l'utilisateur.

Comment nous nous sommes assurés que ce logiciel était évolutif

• Nous avons utilisé une architecture de microservices décentralisée
• Déploiement de trois équilibreurs de charge pour répartir la charge entre différents microservices
• Certaines parties de cette plate-forme étaient auto-évolutives de par leur conception. Si la charge dépassait un certain seuil, une nouvelle instance d'un microservice était automatiquement créée
• Nous avons utilisé six bases de données différentes - quatre PostgreSQL et deux MongoDB. Les bases de données PostgreSQL ont été mises à l'échelle verticalement en cas de besoin. Lors de la conception de l'architecture, nous avons réalisé que certaines des bases de données devraient être mises à l'échelle assez souvent, nous avons donc adopté MongoDB à cette fin, car elles sont plus faciles à mettre à l'échelle horizontalement.
• Traitement asynchrone déployé pour une meilleure expérience utilisateur. Par exemple, le post-traitement vidéo a été effectué de manière asynchrone.
• Nous avons opté pour l'algorithme de reconnaissance faciale d'un fournisseur de services tiers. Nous nous sommes donc assurés de sélectionner une solution déjà évolutive et de l'intégrer à notre plateforme via une API.

Défis que vous pourriez rencontrer lors de la mise à l'échelle

Si vous avez l'intention de planifier l'évolutivité logicielle lors du développement de l'application et que vous souhaitez intégrer les conseils ci-dessus, vous pouvez toujours faire face aux défis suivants :

• Dette technique accumulée . Les parties prenantes du projet peuvent toujours tenter de mettre de côté l'évolutivité au profit de coûts, d'une vitesse, etc. plus faibles. L'évolutivité n'est pas une exigence fonctionnelle et peut être éclipsée par des caractéristiques plus tangibles. De ce fait, l'application accumulera des fonctionnalités techniques qui ne seront pas compatibles avec la scalabilité.
• Mise à l'échelle avec la méthodologie de développement Agile . La méthodologie agile consiste à accepter le changement. Cependant, lorsque le client souhaite implémenter trop de modifications trop souvent, l'évolutivité du logiciel peut être mise de côté pour s'adapter à l'évolution des demandes.
• Tests d'évolutivité . Il est difficile d'effectuer des tests de charge réalistes. Supposons que vous souhaitiez tester le comportement du système si vous augmentez la taille de la base de données 10 fois. Vous devrez générer une grande quantité de données réalistes, qui correspondent à vos caractéristiques de données d'origine, puis générer une charge de travail réaliste pour les écritures et les lectures.
• Évolutivité des services tiers . Assurez-vous que votre fournisseur de services tiers ne limite pas l'évolutivité. Lors de la sélection d'un fournisseur de technologie, vérifiez qu'il peut prendre en charge le niveau d'évolutivité logicielle prévu et intégrez correctement sa solution.
• Comprendre l'utilisation de votre application . Vous devez avoir une vision solide du fonctionnement de votre logiciel et du nombre de personnes qui l'utiliseront, ce qu'il est rarement possible d'estimer avec précision.
• Restrictions architecturales . Parfois, vous êtes limité dans vos choix architecturaux. Par exemple, vous devrez peut-être utiliser une base de données relationnelle et devrez la mettre à l'échelle horizontalement et verticalement.
• Avoir le bon talent . Afin de concevoir une solution évolutive qui ne vous causera pas de maux de tête à l'avenir, vous avez besoin d'un architecte expérimenté qui a déjà travaillé sur des projets similaires et qui comprend l'évolutivité logicielle du point de vue du codage et de l'infrastructure. Chez ITRex Group, nous avons travaillé sur de nombreux projets et gardons toujours à l'esprit l'évolutivité lors du développement de logiciels.

Pour résumer

À moins que vous ne soyez absolument certain que vous n'aurez pas besoin d'évoluer, envisagez l'évolutivité du logiciel aux premières étapes du développement et prenez les précautions nécessaires. Même si vous êtes limité dans vos choix architecturaux et que vous ne pouvez pas toujours mettre en œuvre l'option la plus évolutive, vous saurez toujours où se trouvent les obstacles et aurez le temps d'envisager des alternatives.

Laisser l'évolutivité de côté pour d'autres exigences fonctionnelles se retournera contre vous. Tout d'abord, l'entreprise devra lutter contre la dégradation des performances. Le traitement des demandes prendra trop de temps. Les utilisateurs subiront des retards inacceptables. Après tout cela, l'entreprise évoluera en payant le double et le triple du montant qui aurait pu être dépensé à des stades antérieurs.

Vous envisagez de déployer un nouveau logiciel d'entreprise ou de mettre à jour un système existant, mais vous craignez qu'il ne réponde pas aux besoins commerciaux en pleine expansion ? Entrer en contact! Nous nous assurerons que votre logiciel possède non seulement toutes les fonctionnalités requises, mais peut également être mis à l'échelle avec un investissement et des temps d'arrêt minimaux.

Publié à l'origine sur https://itrexgroup.com le 24 juillet 2023.