Solution hybride ou multicloud
Il n ' y a rien de mal à développer une stratégie hybride ou multicloud . Toutefois , suggérer que la meilleure façon de lutter contre les pannes , comme l ' événement S3 dont nous avons été témoins , est de faire appel à plusieurs prestataires de cloud est peu clairvoyant . Avant d ' investir du temps , de l ' argent et des ressources dans le développement d ' une stratégie multicloud dans le seul but d ' assurer la redondance et la haute disponibilité , considérez les éléments suivants :
1 . Assurez-vous que votre architecture actuelle est conçue pour faire face aux défaillances . Par exemple , AWS recommande la réplication interrégionale pour S3 pour la haute disponibilité et la reprise après sinistre .
2 . Testez vos systèmes face à la défaillance . Si vous partez du principe que toutes les API AWS fonctionneront systématiquement et que vous ne concevez pas et ne testez pas de cas d ' utilisation de défaillance , vous n ' aurez que ce que vous méritez quand le service sera interrompu . Simulez des pannes , testez des solutions de haute disponibilité et de reprise , tirez parti de la Simian Army , etc .
3 . Appréhendez le véritable coût total de possession ( TCO ) lié à l ' ajout d ' un autre prestataire de cloud et ne sous-estimez pas l ' effort .
Le multicloud vaut-il seulement la peine en tant que filet de sécurité ? Je pense qu ' avec tout le buzz autour des conteneurs et des outils comme Terraform , on a l ' impression que tout ce que vous établissez sur un cloud est facile à déplacer vers un autre . Permettez-moi de démentir ce mythe .
Je reconnais que le système d ' exploitation et les machines virtuelles peuvent être ultra-portables . Placez-les dans un conteneur et ils devraient pouvoir être facilement exécutés par n ' importe quel prestataire de cloud ou non cloud ( en supposant que votre configuration ne dépend pas du cloud ). Mais le système d ' exploitation et les machines virtuelles ne sont qu ' un infime aspect de la solution . Il faut aussi aborder la gestion des identités et des accès ( IAM ), la conception du cloud privé virtuel ( VPC ), les outils de sécurité , la mise en réseau , etc .
Je n ' ai pas encore trouvé de solution viable , capable d ' éliminer les API spécifiques aux prestataires de cloud en matière de sécurité et de mise en réseau afin de bénéficier d ' une conception unique pouvant être reproduite . Vous pourriez avancer qu ' une solution PaaS gère tout cela pour vous , mais une intégration unique doit toujours avoir lieu pour chaque cloud . Il y a beaucoup de bons arguments pour et contre les solutions purement PaaS , mais ils feront l ' objet d ' un autre article une prochaine fois .
Une grande quantité de travail est nécessaire en amont pour renforcer ce qu ' AWS appelle la « zone d ' application » ou l ' infrastructure nécessaire à l ' exécution de vos applications . Lorsque vous changez de prestataire de cloud , une grande partie de la zone d ' application n ' est pas transférable . Chaque prestataire de cloud dispose de ses propres API en matière de sécurité et de mise en réseau . Il y a également des intégrations uniques impliquant différents outils de sécurité , de surveillance et de journalisation tiers . De nombreuses implémentations SaaS de ces outils tiers sont soit trop onéreuses , soit dépourvues de l ' ensemble des fonctionnalités requises de leur version non-SaaS . Elles nécessitent donc l ' installation et la gestion de ces outils sur l ' infrastructure des prestataires de cloud . Bien sûr , l ' implémentation de chacun de ces outils est différente pour chaque prestataire de cloud en raison des diverses API de sécurité et de mise en réseau de chaque prestataire de cloud .
Abordons maintenant les coûts . Si vous disposez de centaines de téraoctets de
8 | THE DOPPLER | PRINTEMPS 2017