5 façons de rendre votre application infonuagique invincible, comme Wolverine

Wolverine est l’un des personnages les plus formidables de l’univers de Marvel Comics. Ce n’est pas par sa férocité, ni par le fait qu’il soit canadien ni par ses griffes métalliques indestructibles qui lui sortent des poignets; c’est parce que, peu importe ce qui lui arrive, peu importe le mal qu’on lui fait, il possède un don de guérison qui lui permet de revenir et de continuer à se battre, maintes et maintes fois. Wolverine peut guérir ses blessures en faisant sortir les balles de son corps ou encore, se régénérer, s’il le faut, après une explosion atomique. Il incarne la résilience et représente, de façon métaphorique, les qualités recherchées dans une application infonuagique — un soldat qui n’arrête jamais de se battre pour votre entreprise.

Voici 5 moyens de transformer votre application infonuagique en... Wolverine.

1. Choisissez une infrastructure infonuagique qui est, elle-même, hautement redondante et hautement disponible

Il existe deux façons de concevoir une application à haute disponibilité. La première est de la faire fonctionner sur une architecture résiliente; les architectes deviennent alors responsables et doivent livrer une infrastructure qui n’arrête jamais, peu importe ce qui arrive à l’un ou l’autre de ses composants. La deuxième est de concevoir une application résiliente, où les développeurs de logiciels créent leur application en s’attendant à ce que le matériel sous-jacent défaille et ainsi, s’assurent que l’application s’adaptera en conséquence. C’est un problème qui peut s’avérer difficile à résoudre[1] ou à recruter quelqu’un pour le résoudre; la ligne la plus directe est donc de s’assurer de posséder une architecture résiliente et fiable.

cloud.ca est un bon exemple de nuage conçu pour être une infrastructure hautement résiliente. C’est un nuage privé virtuel[2] où la redondance est incorporée sur chaque couche du matériel sous-jacent. Si l’un des composants défaille, il y en a toujours un autre pour prendre la relève et continuer à le faire fonctionner.

L’avantage d’utiliser une solution hautement disponible au niveau du matériel est que l’écriture de logiciel devient beaucoup plus facile. Les concepteurs peuvent développer leurs applications en ayant confiance au fait que l’infrastructure est parfaite et en jouissant d’un niveau élevé de temps exploitable (cloud.ca a un ANS de 99,99 % du côté de l’infrastructure). Ils n’ont pas à vérifier l’état du stockage persistent ni celui du réseau, car ils ont confiance qu’ils sont toujours en parfaite condition[3]. Cela augmente la rapidité d’innovation dans un environnement de développement qui est extrêmement compétitif.

Une infrastructure souple et robuste permet de mettre en œuvre vers un nuage les applications de fournisseurs indépendants de logiciels traditionnels, en utilisant des outils tels que XenApp ou XenDesktop[4], sans avoir à toutes les réécrire en tant qu’applications Web. Une infrastructure hautement disponible est aussi une bonne solution pour les sites et les applications Web conçus pour fonctionner sur des serveurs traditionnels, non virtualisés.

2. Concevez votre application pour que lors d’une panne, elle passe d’une zone de disponibilité à une autre

Les zones de disponibilité sont des regroupements de machines qui se retrouvent dans le même domaine de défaillance. Dans les grands nuages publics, on retrouve de multiples zones de disponibilité à l’intérieur d’une même région géographique, ce qui permet de reproduire vos données et vos serveurs de production dans un environnement rapproché. Ceci a l’avantage de réduire les coûts de bande passante pour la réplication et de vous donner la capacité de basculer rapidement en cas de défaillance dans une zone.

Il est nécessaire d’implanter un « témoin lumineux » de reprise après sinistre[5] pour répliquer vos données dans une seconde zone de disponibilité. On peut mettre en place des systèmes opérationnels ou automatisés pour un basculement rapide en cas de panne dans la première zone. Aussi, l’implémentation active/active permettra un basculement encore plus rapide vers une seconde zone de disponibilité sans avoir à planifier de nouvelles dispositions pour se préparer au trafic. Vous pouvez aussi équilibrer votre charge de trafic sur plusieurs zones de disponibilité.

3. Concevez votre application pour qu’elle bascule sur une tout autre région lors d’une panne.

Le problème avec l’option multi-AZ, c’est qu’à cause des configurations partagées à l’intérieur d’une même région, plusieurs zones de disponibilité peuvent défaillir au même moment[6]. Le niveau supérieur de redondance provient de la capacité de basculer, lors d’une panne, vers d’autres régions de l’infrastructure du fournisseur infonuagique.

Tout récemment[7], Amazon Web Services a subi une panne majeure au cœur de sa région US-EAST-1. Cette cascade de défaillance exposa les problèmes rencontrés avec les occurrences API et EC2 dans toutes les zones de disponibilité de cette région. Seules les entreprises comme Netflix ont pu se redresser rapidement, car elles étaient prêtes pour un basculement et une reprise après sinistre inter région. Les autres, à cause de cette panne sur toute la région, ont vécu un temps d’arrêt variant de 6 à 8 heures.

La redondance sur de multiples régions est une implémentation plus solide, mais plus coûteuse et plus difficile à mettre en œuvre que l’option à multiples zones de disponibilité.

L'utilisateur Reddit JoeCoT écrit:

[Amazon possède] plusieurs façons de gérer les pannes de zone de disponibilité, mais peu façons de gérer les pannes de régions. Il faut énormément de travail fait sur mesure pour déployer les systèmes à travers plusieurs régions et il n’existe pas d’outils pour le faciliter.

Prenons, par exemple, le système de mon entreprise. Nous avons des serveurs à l’intérieur de toutes les 3 zones de disponibilité dans l’Est, et je vais ajouter des bases de données et serveurs Web en Oregon et à Francfort. Mais lorsque j’ajoute des serveurs dans différentes zones de disponibilité dans l’Est, ils peuvent facilement communiquer entre eux tandis qu’Amazon s’occupe du routage sous-réseau. Mais pour ajouter des serveurs dans d’autres régions, il faut énormément de travail d’installation de réseau privé virtuel fait sur mesure afin de les maintenir sur le même réseau interne.

En ce qui concerne Amazon, Netflix partage avec la communauté, sur son site « Open Source Software Center »[8] ses propres outils et processus. Ces types d’outils peuvent être conçus et adaptés pour l’utilisation combinée avec d’autres nuages publics.

4. Concevez un nuage hybride pour votre application

En combinant un nuage privé (matériel virtualisé avec un hyperviseur comme CloudStack ou OpenStack) et un nuage public (AWS, Azure ou cloud.ca), on obtient un nuage hybride.

Avec un nuage hybride, vous « possédez la base et louez les pics »[9]. Ils vous permettent d’acheter, de planifier et de configurer le matériel selon un niveau d’utilisation de base ou moyen, tout en vous donnant la latitude de passer au nuage public, dans les cas d’importants pics de trafic ou de trafic plus haut que la moyenne à certains moments de l’année[10]. Ainsi, vous n’avez pas à vous approvisionner pour l’année entière afin de servir les périodes de plus fortes demandes.

En matière de contrôle, les nuages hybrides ont des bons et des mauvais côtés. Vous aurez un plus grand sentiment de contrôle de l’infrastructure grâce à votre capacité de gérer le matériel qui compose le nuage privé. En revanche, vous aurez à embaucher une équipe pour gérer cette infrastructure, ces ressources auraient pu être utilisées à meilleur escient pour innover et améliorer votre application. Vous aurez aussi à remplacer, à intervalles de plusieurs années, le matériel sous-jacent — chose dont vous n’avez pas à vous préoccuper avec une infrastructure infonuagique.

Les nuages hybrides s’avèrent souvent être une bonne solution pour les entreprises qui ont beaucoup investi dans du matériel et qui recherchent une capacité de dépassement ou qui désirent faire la transition vers le nuage. Si le matériel est compatible avec un certain nombre de déploiements de nuages privés, on peut profiter du modèle opérationnel du nuage hybride.

5. Utilisez de multiples nuages, régions et zones de disponibilité — le summum de la résilience en infonuagique.

Une solution multi nuages est la solution la plus résistante (et la plus coûteuse) afin de sécuriser votre infrastructure et votre application infonuagique. Il s’agit de l’utilisation de plusieurs nuages (le plus souvent des nuages IaaS publics et/ou privés virtuels tels que AWS, cloud.ca ou Azure) pour équilibrer les charges, la reprise après sinistre et le basculement rapide en cas de panne dans n’importe quel nuage ou n’importe quelle région.

Il y a de nombreux avantages aux multi nuages :

• La haute disponibilité ainsi que la redondance à travers de multiples nuages et systèmes signifient que votre application est conçue pour résister aux défaillances dans n’importe quel nuage IaaS, même lors d’une panne régionale ou même mondiale.
• La redondance géographique — lorsque l’on utilise des zones de disponibilité dans de multiples régions et de multiples nuages — offre une continuité des activités et une protection contre les sinistres à grande échelle et les défaillances de tout le système infonuagique.
• L’effort déployé pour créer votre application sur des nuages multiples signifie que votre approche, en ce qui concerne l’utilisation de l’infrastructure infonuagique, sera des plus classiques permettant la transmutabilité vers de multiples nuages. Vous demeurez libre-penseur dans votre approche opérationnelle.
• L’enfermement à un fournisseur unique est évité (ainsi que la dépendance excessive à ses technologies)[11]. Il y a des systèmes en place qui faciliteront le transfert vers le nuage offrant la meilleure performance, au meilleur prix, et ayant le plus de disponibilité.
• La solution multi nuages vous permet de répondre aux exigences juridictionnelles du stockage de données pour certains pays, états et provinces.
• Un plus grand sentiment de contrôle sur votre destin dans le nuage.

Voici un bon exemple d’infonuagique multi nuages : L'entreprise Peerio utilise les services de cloud.ca et de AWS pour répondre à ses critères de disponibilité et juridictionnels.

Même si le service multi nuages n’est pas encore offert par une seule solution technologique[12], il peut être conçu et géré par une équipe d’experts qui créera une recette opérationnelle conçue spécialement pour la charge de travail de l’application. Des équipes comme CloudOps peuvent vous aider à créer et à configurer votre application pour qu’elle fonctionne dans plusieurs nuages, et soutenir votre plate-forme d’application lorsqu’elle s’y trouve.

Votre choix dépend de vos besoins d’affaires. 

Finalement, c’est vous qui choisirez la ou les solutions selon votre budget et votre analyse de rentabilisation d’implémentation de résilience dans votre application infonuagique. Pour les entreprises où chaque minute, chaque vue et où chaque transaction compte, vous allez vouloir combiner une infrastructure robuste avec une quelconque application multi zones de disponibilité ou multi nuages. Si vous êtes visionnaire et voulez bâtir pour le futur — afin de garder le contrôle de votre propre situation infonuagique — vous pourriez considérer la conception votre application pour qu’elle fonctionne sur de multiples nuages. Cela offre l’atout supplémentaire de la grande portabilité et d’un niveau plus élevé de redondance que lorsqu’on se fie simplement sur le système d’un seul fournisseur.

Suivez-nous sur Twitter et LinkedIn pour recevoir les dernières nouvelles et articles de cloud.ca !

Inscrivez-vous pour un essai de notre infrastructure infonuagique ici.