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éfaillances des fournisseurs de cloud. Les perturbations majeures des clouds semblent devenir plus fréquentes et plus dévastatrices. La région US-East-1 d’AWS, 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 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 nous rappeler 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éfaillances et de problèmes des fournisseurs de cloud ne devraient peut-être pas être 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 cloud va affecter votre application, ni essayer d’ajuster votre infrastructure au vol pendant une défaillance. Au lieu de cela, vous devriez réexaminer ce que vous savez sur le multi-cloud.

Applications multi-cloud

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

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

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-cloud véritable augmente votre puissance de calcul globale et vous permet de résister à ces contraintes. Elle débloque votre capacité à mettre à l’échelle selon les besoins au-delà des limites d’un seul fournisseur, à étendre rapidement la capacité à travers les géographies et à assurer des performances constantes pendant les jours de pointe. Mais avoir une application portable et agnostique en matière de cloud n’est que le premier pas ; le suivant consiste à la déployer dans une architecture vraiment résiliente.

Passer à une approche active-active

Cela nécessite une préparation sérieuse de la part de DevOps. Il est extrêmement difficile d’avoir une stratégie de continuité des activités et de reprise après sinistre (BCDR) à 100 % précise, car lors de l’exécution de vos opérations en direct, il y a de multiples points de défaillance. Vous ne voulez pas tester votre stratégie BCDR pendant une défaillance, vous pouvez donc vous sentir comme si tout ce que vous pouviez vraiment faire était 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éfaille, 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 à fonctionner à une capacité réduite. Si vous avez déjà créé une copie de votre application de travail, une seconde, vous pouvez basculer vers la mise en équilibre de charge afin de pouvoir 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 perturbation pour vos clients.

Le coût réel de ne pas passer au multi-cloud

Même si le coût d’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 leur assurer que cela ne se reproduira pas et les convaincre de ne pas vous quitter pour l’un de vos concurrents. Ne nous oublions pas non plus de tous les revenus manqués en raison des ventes perdues que vous ne pouvez pas regagner. Chez FluidCloud, j’ai vu ce scénario se reproduire à plusieurs reprises : 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 clouds, 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 recommande donc de se concentrer sur les clouds moins chers qui offrent des performances compétitives à un prix inférieur. Si vous avez un secondaire en cours d’exécution dans un cloud moins cher, vous aurez toujours une redondance active-active complète, mais à un coût inférieur. C’est un avantage pour tout le monde.

Pensées finales

Exécuter vos applications en mode actif-actif 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 constante, 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 véritable architecture multi-cloud active-active.