Antimodèles de préparation au cloud

Article
03/22/2023

Les clients sont souvent confrontés à des antimodèles pendant la phase de préparation de l’adoption du cloud. Ces antimodèles peuvent entraîner des arrêts inattendus, des problèmes de récupération d’urgence et des problèmes de disponibilité.

Antimodèle : supposer que les services libérés sont prêts pour la production

Étant donné que le cloud computing évolue rapidement, les entreprises publient souvent des versions préliminaires de nouveaux services. Les clients ont tendance à supposer qu’ils peuvent utiliser n’importe quel service cloud disponible dans un environnement de production. Toutefois, des problèmes peuvent se produire pour les raisons suivantes :

Les services en version préliminaire ne fournissent généralement pas de contrats de niveau de service (SLA) concernant la durée de bon fonctionnement.
Les nouveaux services ne sont souvent pas aussi matures que les services cloud déjà disponibles.

Exemple : utiliser un service en version préliminaire en production

Un institut de recherche utilise un service cloud en version préliminaire en production. Le service semble être adapté à son cas d’usage. En revanche, l’institut n’effectue pas de vérification préalable sur le service. L’Institut ne suit pas non plus les exigences et les recommandations de l’architecture de référence.

Les problèmes sont liés à la version préliminaire du service, qui entraîne des temps d’arrêt inattendus. L’Institut commence à penser que les services cloud en général ne sont pas aussi matures ni résilients que promis.

Résultat préféré : utiliser des services cloud pré-approuvés en production

Lors de l’évaluation de nouveaux services en préversion, n’utilisez ces services que dans des scénarios de preuve de concept (POC). N’utilisez pas ces services dans des environnements de production, car ils n’ont pas de contrat SLA. Trouvez le juste équilibre entre les fonctionnalités et la maturité lors de l’approbation de services cloud. Consultez la liste de vérification des points à vérifier en matière de services cloud pour une infrastructure établie que vous pouvez utiliser pour évaluer rapidement les services cloud.

Antimodèle : hypothèse d’augmentation de la résilience et de la disponibilité

Le cloud computing offre souvent des avantages par rapport à l’informatique locale. Voici quelques exemples :

Résilience accrue : récupération après une défaillance.
Disponibilité : exécution dans un état d’intégrité sans temps d’arrêt significatif.

Étant donné que la plupart des services cloud offrent ces avantages, de nombreuses entreprises partent du principe que tous les services cloud offrent une résilience et une haute disponibilité par défaut. En réalité, ces fonctionnalités ne sont souvent disponibles que moyennant des frais supplémentaires et avec davantage d’efforts techniques.

Exemple : supposer la haute disponibilité

Une start-up implémente une application stratégique sur des services infrastructure as a service (IaaS). Les développeurs de la start-up ont examiné une machine virtuelle avec un contrat SLA de temps d’activité de 99,9 %. Dans la mesure où ils souhaitent réduire les coûts, ils utilisent une machine virtuelle unique et un stockage Premium.

En cas de défaillance de la machine virtuelle, leur application est irrécupérable. Résultats inattendus de temps d’arrêt. Ils avaient supposé que le cloud offre une haute disponibilité par défaut. Ils n’avaient pas conscience du fait que les garanties de performances peuvent être différentes entre :

des modèles de service, tels que le service platform as a service (PaaS) et le software as a service (SaaS) ;
des architectures techniques, telles que des groupes à haute disponibilité avec équilibrage de charge et des zones de disponibilité.

Résultat préféré : réduire les défaillances pendant l’équilibrage de la résilience et des coûts

Consultez des ressources approuvées et éprouvées pour obtenir des informations sur les meilleures pratiques architecturales qui peuvent réduire l’étendue des défaillances :

Identifiez le bon équilibre entre les coûts et les fonctionnalités, telles que la haute résilience et la disponibilité. Une résilience et une disponibilité accrues entraînent généralement une augmentation des coûts. Exemple :

Une seule machine virtuelle peut avoir un contrat SLA avec un temps d’activité garanti de 99,9 %.
Deux machines virtuelles exécutant la même charge de travail opèrent dans le cadre d’un contrat de niveau de service (SLA) avec un temps d’activité de 99,95 % à 99,99 %.

Impliquez-vous dans le processus essentiel de conception des exigences lors de la création d’une solution basée sur le cloud. Utilisez un estimateur SLA pour calculer le contrat SLA de bout en bout de votre application.

Antimodèle : devenir un fournisseur de cloud

Certaines entreprises tentent de faire de leur service informatique interne un fournisseur de cloud. L’informatique devient alors responsable des architectures de référence. Elle doit également fournir IaaS et PaaS aux unités commerciales. Dans la mesure où ce type de travail ne fait généralement pas partie des activités principales du service informatique, les offres de service qui en résultent ne sont pas utilisables, ou peuvent manquer de résilience, de performances et de sécurité.

Exemple : fournir des services cloud monolithiques managés

Le service informatique d’une entreprise établit un centre d’excellence du cloud (CCoE) qui fait office de répartiteur entre les unités informatiques et commerciales. Pour s’assurer que l’entreprise est conforme au cloud, le comité de gestion attribue au CCoE la tâche de fournir des services monolithiques de bout en bout. Le CCoE met en place un portail d’approvisionnement cloud interne que les unités commerciales peuvent utiliser pour commander une machine virtuelle cloud complètement managée en tant que service. Toutefois, le service informatique contrôle qui peut accéder à l’ensemble de la plateforme et l’utiliser. Par conséquent, il empêche activement les unités commerciales de tirer parti de la gamme complète des services fournis par Azure. Les unités commerciales ne peuvent pas accéder au portail cloud. Elles ne bénéficient d’un accès que via le protocole SSH (Secure Shell) et le protocole RDP (Remote Desktop Protocol) au serveur qu’elles commandent.

Pour plusieurs raisons, le CCoE a des difficultés à fournir un service managé monolithique pour encapsuler chaque service disponible dans le cloud :

Le cloud offre un grand nombre de services dans plusieurs domaines de solution. Comparées au développement de solutions IaaS, la conception et la création de solutions pour l’Internet des objets (IoT) requièrent une expertise et des ensembles de compétences différents.
Les services cloud changent fréquemment.
Essayer de fournir des services monolithiques augmente considérablement le délai de commercialisation, avec le service informatique qui gère le processus, et non les unités commerciales.

Résultat préféré : fournir des garde-fous

Lorsque vous adoptez des technologies cloud, le service informatique bénéficie d’une expérience directe du cloud, qui commence par les charges de travail informatiques. Utilisez Microsoft Cloud Adoption Framework pour Azure pour identifier votre premier projet d’adoption.

Utilisez un modèle de fonctionnement de cloud mature, tel que des opérations centralisées qui permettent au service informatique de se charger de définir des garde-fous de plateforme comme la gouvernance. Les unités commerciales peuvent alors adopter des projets cloud de manière sécurisée et cohérente, dirigées par les garde-fous définis par le service informatique.

Envisagez de n’adopter qu’un seul fournisseur de cloud public majeur au début, car toutes les plateformes majeures diffèrent considérablement en ce qui concerne l’installation, la gestion et l’utilisation.

Utilisez des solutions SaaS autant que possible pour les outils informatiques, par exemple :

des référentiels de code ;
l’intégration continue et la livraison continue (CI/CD) ;
des systèmes de collaboration.

Pour les charges de travail cloud, conseillez au service informatique d’utiliser des procédures familières qui fonctionnent en toute sécurité à grande échelle.