L’évolutivité est un composant essentiel des logiciels d’entreprise. La prioriser dès le départ permet de réduire les coûts de maintenance, d’améliorer l’expérience utilisateur et d’accroître l’agilité.

La conception de logiciels est un exercice d’équilibre où les développeurs travaillent pour créer le meilleur produit dans les contraintes de temps et de budget d’un client.

Il est impossible d’éviter la nécessité de faire des compromis. Des compromis doivent être faits afin de répondre aux exigences d’un projet, qu’elles soient techniques ou financières.

Trop souvent, cependant, les entreprises privilégient le coût par rapport à l’évolutivité, voire rejettent totalement son importance. Cela est malheureusement courant dans les initiatives de big data, où les problèmes d’évolutivité peuvent couler un projet prometteur.

L’évolutivité n’est pas une « caractéristique bonus ». C’est la qualité qui détermine la valeur à vie du logiciel, et construire en tenant compte de l’évolutivité permet d’économiser à la fois du temps et de l’argent à long terme.

Qu’est-ce que l’évolutivité ?

Un système est considéré comme évolutif lorsqu’il n’a pas besoin d’être repensé pour maintenir des performances efficaces pendant ou après une forte augmentation de la charge de travail.

La « charge de travail » peut faire référence aux utilisateurs simultanés, à la capacité de stockage, au nombre maximal de transactions traitées ou à tout autre élément qui pousse le système au-delà de sa capacité initiale.

La scalabilité n’est pas une exigence de base d’un programme dans la mesure où un logiciel non scalable peut bien fonctionner avec une capacité limitée.

Cependant, elle reflète la capacité du logiciel à croître ou à changer avec les demandes de l’utilisateur.

Tout logiciel susceptible de s’étendre au-delà de ses fonctions de base – en particulier si le modèle économique dépend de sa croissance – doit être configuré pour l’évolutivité.

Les avantages des logiciels évolutifs

L’évolutivité présente des avantages à long et à court terme.

Au départ, elle permet à une entreprise d’acheter seulement ce dont elle a immédiatement besoin, et non pas toutes les fonctionnalités qui pourraient être utiles plus tard.

Par exemple, une entreprise qui lance un programme pilote d’intelligence des données pourrait choisir un ensemble massif d’analyse d’entreprise, ou elle pourrait commencer avec une solution qui ne gère que les fonctions dont elle a besoin au début.

Un choix populaire est un tableau de bord qui tire les résultats de leurs sources de données primaires et des logiciels d’entreprise existants.

Quand ils deviennent assez grands pour utiliser plus de programmes d’analyse, ces flux de données peuvent être ajoutés dans le tableau de bord au lieu de forcer l’entreprise à jongler avec plusieurs programmes de visualisation ou à construire un système entièrement nouveau.

Construire de cette façon prépare la croissance future tout en créant un produit plus mince qui répond aux besoins actuels sans complexité supplémentaire.

Il nécessite également une mise de fonds initiale plus faible, ce qui est une considération majeure pour les dirigeants inquiets de l’ampleur des investissements dans le big data.

L’évolutivité laisse également de la place pour les changements de priorités. Cet ensemble analytique prêt à l’emploi pourrait perdre de sa pertinence lorsqu’une entreprise change pour répondre aux demandes d’un marché en évolution.

Le choix de solutions évolutives protège l’investissement technologique initial. Les entreprises peuvent continuer à utiliser le même logiciel plus longtemps car il a été conçu pour évoluer avec elles.

Lorsqu’il est temps de changer, s’appuyer sur un logiciel solide et évolutif est considérablement moins coûteux que d’essayer d’adapter des programmes moins agiles.

Il y a également un temps de  » montée en puissance  » plus court pour mettre en ligne de nouvelles fonctionnalités que pour mettre en œuvre un logiciel entièrement nouveau.

Comme avantage secondaire, le personnel n’aura pas besoin de beaucoup de formation ou de persuasion pour adopter ce système mis à niveau. Ils sont déjà familiarisés avec l’interface, de sorte que le travail avec les fonctionnalités supplémentaires est considéré comme un bonus plutôt qu’une corvée.

Les retombées des échecs de mise à l’échelle

Alors, que se passe-t-il lorsque le logiciel n’est pas évolutif ?

Au début, la faiblesse est difficile à repérer. La charge de travail est légère dans les premiers stades d’une application. Avec relativement peu d’utilisateurs simultanés, il n’y a pas beaucoup de demande sur l’architecture.

Lorsque la charge de travail augmente, les problèmes apparaissent. Plus le logiciel collecte de données stockées ou d’utilisateurs simultanés, plus l’architecture du logiciel est sollicitée.

Les limitations qui ne semblaient pas importantes au début deviennent un obstacle à la productivité. Les correctifs peuvent atténuer certains des premiers problèmes, mais les correctifs ajoutent de la complexité.

La complexité rend le diagnostic des problèmes sur une base continue plus fastidieux (traduction : plus cher et moins efficace).

A mesure que la charge de travail augmente au-delà de la capacité du logiciel à évoluer, les performances diminuent.

Les utilisateurs connaissent des temps de chargement lents parce que le serveur prend trop de temps pour répondre aux demandes. D’autres problèmes potentiels incluent une diminution de la disponibilité ou même la perte de données.

Tout cela décourage l’utilisation future. Les employés trouveront des solutions de contournement pour les logiciels non fiables afin d’accomplir leur propre travail.

Cela fait courir à l’entreprise le risque d’une violation de données ou pire.

Lorsque le logiciel est en contact avec le client, le manque de fiabilité augmente le potentiel de désabonnement.

Google a constaté que 61% des utilisateurs ne donneront pas une seconde chance à une application s’ils ont eu une mauvaise première expérience. 40% vont directement vers le produit d’un concurrent à la place.

Les problèmes d’évolutivité ne sont pas seulement une erreur de débutant faite par les petites entreprises, non plus. Même Disney a eu des problèmes avec le lancement initial de son application Applause, qui était censée donner aux téléspectateurs un moyen supplémentaire d’interagir avec leurs émissions Disney préférées. L’application n’a pas pu gérer le flot d’utilisateurs de vidéos en streaming simultanées.

Les fans frustrés ont laissé des critiques négatives jusqu’à ce que l’application n’ait qu’une seule étoile dans le magasin Google Play. Les responsables de Disney ont dû retirer l’application pour réparer les dégâts, et la publicité négative a été si intense qu’elle n’a jamais été remise en ligne.

Définir les priorités

Certaines entreprises ne parviennent pas à donner la priorité à l’évolutivité parce qu’elles n’en voient pas l’utilité immédiate.

L’évolutivité est mise de côté au profit de la vitesse, de cycles de développement plus courts ou d’un coût plus faible.

Il existe en fait des cas où l’évolutivité n’est pas une priorité majeure.

Un logiciel destiné à être un prototype ou une preuve de concept à faible volume ne deviendra pas assez gros pour causer des problèmes.

De même, les logiciels internes des petites entreprises avec une faible limite fixe d’utilisateurs potentiels peuvent établir d’autres priorités.

Enfin, lorsque la conformité ACID est absolument obligatoire, l’évolutivité passe après la fiabilité.

En règle générale, cependant, l’évolutivité est plus facile et moins gourmande en ressources lorsqu’elle est considérée dès le début.

Pour commencer, le choix de la base de données a un impact énorme sur l’évolutivité. La migration vers une nouvelle base de données est coûteuse et prend du temps. Ce n’est pas quelque chose qui peut être facilement fait plus tard.

Principes d’évolutivité

Plusieurs facteurs affectent l’évolutivité globale du logiciel :

Usage

L’usage mesure le nombre d’utilisateurs ou de connexions simultanées possibles. Il ne devrait pas y avoir de limites artificielles à l’utilisation.

L’augmenter devrait être aussi simple que de mettre plus de ressources à la disposition du logiciel.

Données maximales stockées

Ceci est particulièrement pertinent pour les sites comportant beaucoup de données non structurées : contenu téléchargé par les utilisateurs, rapports de site et certains types de données marketing.

Les projets de science des données entrent également dans cette catégorie. La quantité de données stockées par ces types de contenu pourrait augmenter de façon spectaculaire et inattendue.

La question de savoir si le maximum de données stockées peut évoluer rapidement dépend fortement du style de base de données (serveurs SQL vs NoSQL), mais il est également essentiel de prêter attention à une indexation appropriée.

Code

Les développeurs inexpérimentés ont tendance à négliger les considérations de code lors de la planification de l’évolutivité.

Le code doit être écrit de manière à pouvoir être ajouté ou modifié sans refactorer l’ancien code. Les bons développeurs visent à éviter la duplication des efforts, en réduisant la taille et la complexité globales de la base de code.

Les applications augmentent effectivement en taille au fur et à mesure qu’elles évoluent, mais garder le code propre minimisera l’effet et empêchera la formation de « code spaghetti ».

Scaling Out Vs Scaling Up

La mise à l’échelle vers le haut (ou « mise à l’échelle verticale ») implique une croissance en utilisant du matériel plus avancé ou plus fort. L’espace disque ou une unité centrale de traitement (CPU) plus rapide est utilisé pour gérer la charge de travail accrue.

La mise à l’échelle vers le haut offre de meilleures performances que la mise à l’échelle vers le bas. Tout est contenu dans un seul endroit, ce qui permet des retours plus rapides et moins de vulnérabilité.

Le problème de la mise à l’échelle est qu’il n’y a qu’un espace limité pour croître. Le matériel devient plus cher à mesure qu’il devient plus avancé. À un certain point, les entreprises se heurtent à la loi des rendements décroissants sur l’achat de systèmes avancés.

Il faut également du temps pour mettre en œuvre le nouveau matériel.

En raison de ces limitations, la mise à l’échelle verticale n’est pas les meilleures solutions pour les logiciels qui doivent croître rapidement et avec peu de préavis.

La mise à l’échelle vers l’extérieur (ou « mise à l’échelle horizontale ») est beaucoup plus largement utilisée à des fins d’entreprise.

Lors de la mise à l’échelle vers l’extérieur, le logiciel se développe en utilisant plus de matériel – et non pas plus avancé – et en répartissant la charge de travail accrue sur la nouvelle infrastructure.

Les coûts sont plus faibles car les serveurs ou les CPU supplémentaires peuvent être du même type que ceux actuellement utilisés (ou tout type compatible).

La mise à l’échelle se produit plus rapidement, aussi, puisque rien ne doit être importé ou reconstruit.

Il y a cependant un léger compromis dans la vitesse. Les logiciels mis à l’échelle horizontalement sont limités par la vitesse avec laquelle les serveurs peuvent communiquer.

La différence n’est pas assez importante pour être remarquée par la plupart des utilisateurs, cependant, et il existe des outils pour aider les développeurs à minimiser cet effet. Par conséquent, la mise à l’échelle est considérée comme une meilleure solution lors de la construction d’applications évolutives.

Lignes directrices pour la construction de systèmes hautement évolutifs

Il est à la fois moins coûteux et plus facile de prendre en compte l’évolutivité pendant la phase de planification. Voici quelques bonnes pratiques pour intégrer l’évolutivité dès le départ :

Utiliser un logiciel d’équilibrage de charge

Le logiciel d’équilibrage de charge est essentiel pour les systèmes avec une infrastructure distribuée (comme les applications mises à l’échelle horizontalement).

Ce logiciel utilise un algorithme pour répartir la charge de travail entre les serveurs afin de s’assurer qu’aucun serveur ne soit submergé. C’est une nécessité absolue pour éviter les problèmes de performance.

L’emplacement compte

Un logiciel évolutif en fait autant que possible près du client (dans la couche app). La réduction du nombre de fois où les apps doivent naviguer dans le trafic plus lourd près des ressources centrales conduit à des vitesses plus rapides et à moins de stress sur les serveurs.

L’informatique de pointe est un autre élément à prendre en compte. Avec un plus grand nombre d’applications nécessitant des ressources importantes, le fait de garder autant de travail que possible sur l’appareil réduit l’impact des zones à faible signal et des retards de réseau.

Cache lorsque cela est possible

Soyez conscient des problèmes de sécurité, mais la mise en cache est un bon moyen de ne pas avoir à effectuer la même tâche encore et encore.

Diriger avec API

Les utilisateurs se connectent à travers une variété de clients, donc diriger avec API qui ne supposent pas un type de client spécifique peut servir à tous.

Traitement asynchrone

Il se réfère aux processus qui sont séparés en étapes discrètes qui n’ont pas besoin d’attendre que la précédente soit terminée avant d’être traitée.

Par exemple, un utilisateur peut recevoir une notification  » envoyé ! » alors que le courriel est encore techniquement en cours de traitement.

Le traitement asynchrone élimine certains des goulots d’étranglement qui affectent les performances des logiciels à grande échelle.

Limiter l’accès simultané à des ressources limitées

Ne pas dupliquer les efforts. Si plus d’une requête demande le même calcul à la même ressource, laissez la première terminer et utilisez simplement ce résultat. Cela ajoute de la vitesse tout en réduisant la pression sur le système.

Utiliser une base de données évolutive

Les bases de données NoSQL ont tendance à être plus évolutives que SQL. SQL met à l’échelle les opérations de lecture assez bien, mais quand il s’agit d’opérations d’écriture, il entre en conflit avec les restrictions destinées à appliquer les principes ACID.

La mise à l’échelle de NoSQL nécessite une adhésion moins stricte à ces principes, donc si la conformité ACID n’est pas une préoccupation, une base de données NoSQL peut être le bon choix.

Envisager des solutions PaaS

La plateforme en tant que service soulage beaucoup de problèmes d’évolutivité puisque le fournisseur PaaS gère la mise à l’échelle. La mise à l’échelle peut être aussi simple que la mise à niveau du niveau d’abonnement.

Regardez dans FaaS

La fonction en tant que service a évolué à partir de PaaS et est très étroitement liée. L’informatique sans serveur fournit un moyen de n’utiliser que les fonctions nécessaires à un moment donné, réduisant ainsi les demandes inutiles sur l’infrastructure back-end.

FaaS est encore en cours de maturation, mais il pourrait valoir la peine d’être examiné comme un moyen de réduire les coûts opérationnels tout en améliorant l’évolutivité.

N’oubliez pas la maintenance

Paramétrez le logiciel pour des tests et une maintenance automatisés afin que, lorsqu’il se développe, le travail de maintenance ne devienne pas incontrôlable.

Construisez avec un œil sur l’avenir

La priorisation de l’évolutivité prépare votre entreprise au succès. Envisagez-la tôt, et vous récolterez les avantages en matière d’agilité lorsqu’elle est le plus nécessaire.

Vous recherchez un logiciel qui peut évoluer avec votre entreprise ? Fixez un rendez-vous gratuit avec l’un de nos développeurs pour parler de l’endroit où vous devez aller et de la façon dont nous pouvons vous y amener !

.