[0:01]Depuis 7 ans, j'ai scalé un bon nombre de start-up et d'architecture. Dans certains cas, ça a été relativement facile et en quelques jours on a pu construire une infrastructure pour gérer des millions d'utilisateurs. Mais par contre dans d'autres cas, ça a été très très compliqué. Dans l'épisode d'aujourd'hui, je vais vous expliquer de manière très simple et non technique ce qu'il y a à savoir sur la scalabilité d'une solution et surtout ce qu'il faut demander aux développeurs pour que ça scale facilement.
[0:34]Bienvenue, vous êtes fondateur, vous n'avez pas de compétences techniques, pas de panique avec le start-up snack, on vous donne toutes les clés pour piloter votre start-up sereinement et c'est disponible sur YouTube et sur podcast. Je m'appelle Amaury, je suis le fondateur de My CTO Friend et depuis 2013, j'ai accompagné des centaines de start-up en tant que CTO. Alors, pour aujourd'hui, je vais utiliser deux exemples de start-up avec lesquelles j'ai travaillé du durant ces ces dernières années. La première est une start-up qui était dans l'EdTech, dans dans le monde de l'éducation et qui euh et qui avait un logiciel qui avait été développé vraiment sur mesure, qui était vraiment pas adapté à devenir scalable, à devenir scalable. Et donc il a fallu l'adapter, le transformer, ajouter des composants et cetera et ça a pris plus de 6 mois pour être capable de gérer plus de 2000 utilisateurs simultanés. D'un autre côté, j'ai eu un autre projet avec qui ça a été très très simple. On l'a fait en quelques jours. Il a juste fallu scaler l'architecture et non pas scaler le logiciel et c'est là qu'il y a eu une la toute et toute la différence. Parce que dans certains cas, il va falloir transformer le code, l'adapter, transformer les composants, changer la logique et cetera. Dans un autre cas, on va juste déployer de nouveaux serveurs, de nouveaux services et ça scale tout seul. Et c'est ça qui va faire la différence entre les deux. Alors, pour comprendre bien le fond le fondement de tout ça, il y a déjà deux manières de scaler une architecture, deux manières de scaler un logiciel. Premièrement, la plus simple, c'est ce qu'on va appeler la scalabilité verticale. Autrement dit, nous allons prendre un notre serveur et ce qu'on va faire, c'est qu'on va le remplacer par un serveur plus puissant. C'est généralement le premier réflexe, c'est ce qu'il y a de plus facile à faire, mais ça a certaines limites puisque ça aura la limite de ce gros serveur et puis potentiellement de malfaçon dans le logiciel. Deuxième solution, et la meilleure évidemment, c'est de faire ce qu'on va appeler une une scalabilité horizontale. C'est-à-dire que au lieu de remplacer un autre serveur par de plus gros serveur, et ben on va simplement le remplacer par plusieurs autres serveurs et pas forcément plus gros d'ailleurs, juste d'autres serveurs. Et cette deuxième solution a deux avantages. Premièrement, c'est que si jamais il y a un des serveurs qui échoue, dans ce cas-là, il n'y a pas de souci, hop, on va basculer sur un autre serveur. C'est ce qu'on va appeler de la haute disponibilité. Et la deuxième, le deuxième gros avantage, c'est qu'il y a quasiment pas de limite, parce que plus nous allons avoir de requêtes, et ben plus on déploiera de serveurs et c'est comme ça qu'on fait tourner un Facebook ou un Google, sans avoir cette limite du euh serveur en lui-même. Alors, maintenant que vous comprenez ce concept, on va rentrer un peu plus dans le détail sur finalement, qu'est-ce qui rend une application compatible avec la scalabilité horizontale. Et c'est vraiment le point de la de la vidéo d'aujourd'hui, de ce qu'il faut faire attention quand on va lancer les développements de votre solution pour que ça soit scalable. Alors, vous devez peut-être savoir que n'importe quel logiciel est composé de trois composants. On a l'application, ce que l'on va exécuter, donc souvent sur un serveur. Nous allons avoir les fichiers de l'utilisateur qu'on va devoir stocker et nous allons avoir la base de données. Et donc le problème avec la scalabilité horizontale, et ben c'est comme on va utiliser plein de serveurs, et ben on ne peut rien stocker sur ces serveurs, ni fichier utilisateur, ni base de données. La seule chose qui sera stockée sera finalement l'application qui aura été copiée juste quand on aura lancé ses serveurs. Donc le problème et ben c'est que il va bien falloir stocker ces informations quelque part et la solution c'est de les stocker sur ce qu'on appelle un cluster. Alors un cluster c'est quoi ? Un cluster c'est un groupe de serveurs qui vont avoir qu'un seul et même rôle. Par exemple, exécuter des applications ou stocker des fichiers ou stocker une base de données. Et c'est de cette manière-là que l'on va pouvoir euh scaler un service et donc de pouvoir aller beaucoup plus loin. Alors, il y a des tout un tas de types de clusters. Là, je vous ai parlé des trois principaux, mais il y en a pour du Big Data, pour de l'intelligence artificielle et cetera, il y a plein de types de clusters qui existent. Et c'est aussi ce qu'on appelle un peu plus communément maintenant les services cloud. En fait, un service cloud, qu'est-ce que c'est ? Un service cloud, c'est juste un cluster qui est managé. C'est-à-dire qu'on a pas besoin de gérer soi-même plein de serveurs, des connecter entre eux, de faire tout un travail de supervision, si en a un qui crache et cetera. Tout ce travail qui est extrêmement complexe, on le donne à Google, à Amazon et cetera, on le donne à des cloud provider et c'est leur boulot de nous mettre à disposition un cluster opérationnel.
[5:07]Et c'est comme ça qu'on va pouvoir scaler facilement, relativement facilement, je veux dire, une start-up. La seule chose que nous avons à faire en tant que start-up et surtout vos équipes techniques, ce qu'ils doivent faire, c'est d'utiliser les services standards pour être compatible avec un ben des solutions cloud ou les solutions qui sont euh compatibles en mode cluster. Alors, s'il y a bien quelque chose qu'il va falloir demander à votre développeur, en fait ça se résume quasiment en une seule chose en un seul mot, un mot un peu complexe, c'est le mot stateless. Alors, qu'est-ce que ça veut dire stateless, ça veut dire simplement que c'est compatible avec de la scalabilité horizontale. Autrement dit, ça veut dire que l'on ne stocke rien sur le serveur, on a rien de stable stateless, on stocke rien de stable sur le serveur. Et on va pouvoir donc utiliser des services annexes, des services qui sont compatibles avec les clusters, avec les services cloud pour stocker les données qui sont réellement importantes, généralement base de données, fichiers et éventuellement d'autres services si nécessaire.
[6:09]On va généralement télécharger aussi l'application quand on lance le serveur. Bref, techniquement pour rester très simple, vous pouvez très bien avoir une solution compatible scalabilité horizontale, stateless mais avoir qu'un seul et même serveur. Je vous dis pas qu'il faut lancer une start-up avec 10 serveurs, une grosse infrastructure et cetera. Non non non non, surtout pas, il faut faire les choses très très simplement et vous pouvez avoir qu'un seul et même serveur juste utiliser les services qui sont compatibles et qui sont standards. Voilà, donc ça c'est ce qu'il faut demander à votre développeur. 1, toujours stocker les fichiers utilisateur sur un service distribué. 2, utiliser une base de données et un framework standard comme ça c'est scalable et c'est surtout que il y a d'autres personnes qui ont déjà scalé avec ce type de base de données et avec ce type de framework. Ne pas utiliser de script particulier un peu lourd sur le serveur web parce que ça ça va ralentir vos performances et c'est ça qui généralement souvent fera cracher si jamais il y en a. 4, stocker les sessions dans une base de données spécifique comme ça on est compatible, on ne stocke rien en local et les utilisateurs que seront connectés ne perdront pas leur session si on passe d'un serveur à l'autre.
[7:18]Alors maintenant que nous avons atteint ce niveau de de détail, vous allez vous demander mais comment ça va se passer pour moi, je suis fondateur non technique, quelles sont les étapes par lesquelles je vais devoir passer.
[7:33]Alors la toute première étape, elle est extrêmement simple et vous pouvez la réaliser par vous-même. La toute première étape, c'est d'utiliser ce qu'on va appeler un CDN. Alors un CDN, c'est common distributed network, c'est un réseau de clusters qui vont pouvoir distribuer les contenus statiques et qui sont généralement distribués tout autour du monde. Autrement dit, quand vous allez avoir un fichier, par exemple une image dans votre application, et ben un serveur aux États-Unis, en Inde, peu importe où seront vos vous positionner vos clients. le à chaque fois que un utilisateur va demander cette image, on va vérifier si oui ou non dans le réseau CDN, cette image est disponible. Si elle est, ben on envoie cette copie. Si elle ne l'est pas, on vient solliciter votre serveur. Et rien que installer ça avec une solution comme CloudFlare, par exemple, ça va vous économiser plus de 70 % des requêtes sur votre serveur et donc ça retardera le moment où il faudra scaler votre architecture. Maintenant, la prochaine euh dans dans la phase de croissance, la prochaine euh prochain challenge, j'ai envie de dire, le prochain goulot d'étranglement, ça sera forcément sur vos bases de données. Alors, les solutions pour les bases de données sont multiples et elles sont spécifiques. Généralement, on va avoir des bases de données qu'il va falloir optimiser pour le moteur de recherche. Une autre base de données qui sera utilisée peut-être pour des plus grosses bases de données, pour des Big Data, peut-être une base de données qui sera dédiée aux interactions temps réel comme par exemple sur un chat et cetera. On a aussi on parle aussi souvent de services queue, de feed d'attente et on peut aussi avoir des bases de données qui sont dédiées pour tout ce qui est stockage court terme, on va dire. Typiquement le nombre de likes ou le genre de choses qui n'ont pas besoin d'être modifié fréquemment, mais qui seront synchronisées avec la base de données principale. Et c'est comme ça qu'on va pouvoir euh scaler votre architecture. Mais vous savez que ce type d'architecture à un moment donné euh vont devenir un petit peu complexes. Alors, généralement, un bon architecte va vous aider à définir ce ce type d'architecture. Et c'est d'ailleurs quelque chose qu'on fait avec les start-ups qu'on accompagne à My CTO Friend. Mais il va falloir souvent passer à la phase d'après ou quand vous allez avoir 10, 15 serveurs à gérer, bah ça va devenir très compliqué. Donc vous allez devoir avoir une équipe qui gère ça ou potentiellement outsourcer ou demander à une société de gérer votre infrastructure et on va utiliser dans ce cas-là ce qu'on appelle euh de l'infrastructure à code. Alors, qu'est-ce que c'est que l'infrastructure à code ? L'infrastructure à code, c'est tout simplement un script qui va vous permettre de redéployer la totalité de votre infrastructure. Autrement dit, ben vous allez pouvoir euh lancer dans le cas où votre data center crash si il prend feu ou ou si jamais vous perdez complètement les serveurs qui sont sur un site, ben vous allez pouvoir relancer vos vos sauvegardes et votre application et vos 10 serveurs et tous vos services en genre 10 ou 15 minutes, juste en ayant lancé ce script d'infrastructure à code.
[10:22]Et ça c'est extrêmement un extrêmement appréciable. Et donc le dernier point que je n'ai pas forcément détaillé mais c'est qu'à un moment donné, vous allez devoir dans votre phase de croissance basculer sur le cluster d'application distribuée. J'en ai parlé en tout début, il va falloir tôt ou tard basculer d'un seul et même serveur à plusieurs serveurs. Souvent, c'est soit un peu avant, soit un peu après la base de données, mais ça c'est généralement quasiment en même temps que l'on revoit l'infrastructure et donc on va passer sur un cluster d'application. Et là le cluster d'application travaillera avec ce qu'on appellera un lot de balancer, qui fera de la redirection. Voilà, mais je vous passe maintenant les détails. Ce qui est important de retenir, c'est que finalement la scalabilité, ce n'est pas qu'une question d'être capable de gérer une grande quantité d'utilisateurs, mais c'est aussi être question de gérer de la haute disponibilité pour vous permettre en cas d'incident sur un data center, sur des serveurs, et ben de pouvoir quand même délivrer un service, quand même délivrer votre application et ne pas atteindre à votre réputation.
[11:18]Donc, conclusion de cet épisode, pour avoir une application scalable, il faut qu'elle soit stateless et ça veut dire stocker des fichiers sur un service distribué de type Amazon S3 par exemple. Utiliser des bases de données et des frameworks qui sont standards, ça, je ne pourrai jamais le répéter assez. Ne faites pas des choses qui soient trop en dehors des sentiers battus, parce que on n'a pas de retour d'expérience sur des technologies qui sont pas suffisamment éprouvées. Utiliser un CDN, déployer une application un cluster d'application, je veux dire comme ça vous allez pouvoir scaler manière horizontale votre application et utiliser des bases de données spécifiques et optimiser pour chaque besoin, c'est comme ça que vous allez pouvoir euh retirer ce goulot d'étranglement que vous allez avoir sur votre application. Vous savez, les logicielles la scalabilité logicielle est quelque chose d'assez pointu et qui demande un assez haut niveau d'expertise, c'est pour ça qu'on parle d'architecte logiciel. Si vous avez suivi les recommandations de cet épisode, celle que je vous ai juste partagé et que vous les avez partagés avec votre développeur, vous devriez normalement pouvoir économiser déjà un bon paquet de budget sur vos développements futurs, sur votre phase de croissance et également beaucoup beaucoup de temps et vous serez donc beaucoup plus rapide pour de vos développements. Voilà, si vous avez aimé cette vidéo, bah likez, abonnez-vous et pour recevoir évidemment chaque semaine les astuces sur comment monter et scaler sa start-up. Si vous avez des questions ou vous avez un sujet à suggérer, faites-le en commentaire ci-dessous. Si vous voulez en savoir plus sur notre programme dédié aux start-ups, rendez-vous sur MyCTOFriend.com. À très bientôt !
