Pourquoi votre site e-commerce a besoin d’une approche multi-nuage active-active cette saison des fêtes

Pour les dirigeants du commerce électronique, les fêtes apportent deux certitudes : un afflux massif d’acheteurs et un risque accru de défaillance des fournisseurs de cloud. Les perturbations majeures du cloud semblent devenir plus fréquentes et plus dévastatrices. La région AWS US-East-1, par exemple, a une histoire de perturbations importantes pendant la saison des fêtes. De même, chaque année autour de janvier, Microsoft Azure tend à avoir des problèmes de latence réseau ou des défaillances de réseau en raison de son plan de publication ou de test dans certaines régions. Et nous n’avons qu’à regarder en arrière à ce passé juin, lorsque une défaillance majeure de Google Cloud a touché un large éventail d’applications, pour être rappelé que aucun fournisseur unique n’est à l’abri.

Si vous êtes responsable d’une opération de commerce électronique, vous ne voulez pas découvrir que même si vous avez tout configuré correctement, quelque chose a cessé de fonctionner pendant la période la plus critique de l’année. Ces tendances de défaillance et de problème de fournisseur de cloud ne sont peut-être pas sur votre radar, et franchement, elles ne devraient pas l’être. Si vous êtes un ingénieur de fiabilité de site, vous ne devriez pas vous inquiéter de savoir si une défaillance de plate-forme de cloud va affecter votre application, ni essayer d’ajuster votre infrastructure au vol pendant un problème. Au lieu de cela, vous devriez réexaminer ce que vous savez sur le multi-nuage.

Applications multi-nuage

Si votre organisation paie des frais AWS, Azure et GCP, vous avez effectivement les trois nuages à votre disposition. Cela dit, même si vous utilisez les trois, il est important d’examiner ce qui se passe lorsque vous allez un peu plus loin. Certaines de vos applications sont-elles spécifiques à AWS, Azure ou GCP ? Continueront-elles à fonctionner si un fournisseur de cloud est défaillant et que vous devez rapidement basculer vers un autre ?

Votre application doit fonctionner parfaitement sur n’importe lequel des nuages. C’est ce qu’est une véritable configuration multi-nuage. Si vous voulez être agnostique au cloud, vous ne pouvez pas simplement payer pour le multi-nuage ; vous devez vous assurer que vos applications sont également multi-nuage.

De plus, s’appuyer sur un seul fournisseur introduit des contraintes inhérentes sur la capacité de calcul, la limitation des taux d’API et la disponibilité régionale. Une architecture multi-nuage véritable augmente votre puissance de calcul globale et vous permet de résister à ces contraintes. Elle débloque votre capacité à mettre à l’échelle sur demande au-delà des limites d’un seul fournisseur, à étendre rapidement la capacité à travers les géographies et à assurer des performances cohérentes pendant les jours de pointe de vente. Mais avoir une application portable et agnostique au cloud n’est que le premier pas ; le suivant est de la déployer dans une architecture vraiment résiliente.

Mise à l’échelle vers une approche active-active

Cela nécessite une préparation sérieuse de la part de DevOps. Il est incroyablement difficile d’avoir une stratégie de continuité des activités et de reprise en cas de sinistre (BCDR) à 100 % précise, car lorsqu’il s’agit d’exécuter vos opérations en direct, il y a de multiples points de défaillance. Vous ne voulez pas tester votre stratégie BCDR en cas de défaillance, vous pouvez donc vous sentir que tout ce que vous pouvez vraiment faire est de prédire les scénarios possibles, puis de vous préparer en conséquence.

Mon conseil aux ingénieurs de fiabilité de site est d’architecturer pour la défaillance par défaut. Cela signifie avoir un cloud secondaire ou même tertiaire en cours d’exécution dans un état actif. Une stratégie BCDR limitée à un seul fournisseur est un point de défaillance unique ; si le plan de contrôle ou le réseau principal du fournisseur défaillit, votre plan de reprise entier est rendu inutile.

Pendant la saison des fêtes, il est courant que le nombre de visiteurs augmente soudainement, forçant votre plate-forme ou votre application à commencer à fonctionner à une capacité réduite. Si vous avez déjà créé une copie de votre application de travail, une secondaire, vous pouvez basculer vers l’équilibrage de charge afin que vous puissiez détourner certaines requêtes vers l’autre instance de votre application.

Cette approche active-active signifie que vous avez votre produit complet dupliqué, en cours d’exécution ailleurs. Si votre fournisseur de cloud principal connaît une dégradation ou une défaillance grave, vous pouvez basculer sans heurt 100 % de votre trafic vers le fournisseur secondaire via DNS ou un équilibreur de charge global, en faisant de celui-ci le point d’entrée principal sans interruption pour vos clients.

Le véritable coût de ne pas adopter le multi-nuage

Même si le coût de l’exécution d’un cloud secondaire n’est pas négligeable, il est insignifiant par rapport à l’impact commercial d’une défaillance majeure : s’excuser auprès des clients après une défaillance de fiabilité, essayer de les assurer qu’il ne se reproduira pas et les convaincre de ne pas vous quitter pour l’un de vos concurrents. N’oublions pas non plus tous les revenus manqués des ventes que vous ne pouvez pas regagner. Chez FluidCloud, j’ai vu ce scénario se produire encore et encore : les entreprises investissent lourdement dans un seul fournisseur, pour se retrouver du mauvais côté d’une défaillance sans recours immédiat.

Cela dit, il est déjà suffisamment difficile de contrôler vos coûts si vous n’utilisez qu’un seul fournisseur de cloud ; vos coûts de cloud ressemblent probablement à un graphique exponentiel. Si vous adoptez plusieurs nuages, ce graphique exponentiel ne fera que paraître encore plus abrupt.

Lorsque vous dupliquez votre infrastructure à partir de votre cloud principal, vous ne voulez naturellement pas que vos coûts doublent. Je vous recommande donc de vous concentrer sur les nuages moins chers qui offrent des performances compétitives à un prix inférieur. Si vous avez une instance secondaire en cours d’exécution dans un nuage moins cher, vous aurez toujours une redondance active-active complète, mais à un coût inférieur. C’est un avantage mutuel.

Pensées finales

Exécuter vos applications en mode active-active sur plusieurs fournisseurs de cloud ne signifie pas simplement créer une sauvegarde. Cela signifie construire une résilience en temps réel, vous assurer que votre entreprise n’a pas de point de défaillance unique et être en mesure d’offrir une vitesse constante même pendant les pics de trafic.

Cette saison des fêtes, ne vous contentez pas d’espérer la fiabilité. Construisez-la. Concevez vos systèmes pour fonctionner de manière cohérente, quelle que soit la défaillance du fournisseur de cloud ou de la région. Offrez une expérience client sans faille en adoptant une architecture multi-nuage véritablement active-active.