7 étapes pour simplifier la migration des architectures vers le cloud.
La bonne nouvelle est que si vous êtes comme la plupart des entreprises, vous l’avez déjà fait. Plusieurs fois. Environ tous les trois à cinq ans, vous révisez vos architectures de base. Vous ajustez la manière dont vous livrez les candidatures. Vous vous efforcez d’augmenter les performances, d’améliorer la sécurité et de réduire les coûts.
La mauvaise nouvelle est qu’avec le cloud, les choses seront encore plus compliquées. Vous n’avez peut-être pas le contrôle sur les services. Vous ne pourrez peut-être pas coder en dur les connexions ou faire les choses à l'ancienne. Il y aura de la douleur. Mais comme on dit : « Sans douleur, pas de gain », n’est-ce pas ? Vous devrez planifier le comportement des utilisateurs, la connectivité et la bande passante appropriée.
Pour rendre la transition un peu plus fluide, nous avons compilé sept étapes importantes pour vous aider à démarrer.
Quel est l'état de vos candidatures ? Combien en as-tu ? Quelle importance ont-ils pour votre entreprise ? Quels types de données contiennent-ils et, plus important encore, quelles sont les dépendances entre eux ?
Commencez à réfléchir aux catégories dans lesquelles vos applications seront classées. Vous avez quatre options :
Commencez par la partie facile. Identifiez les applications de votre portefeuille qui sont des produits virtuels. Vous en aurez probablement beaucoup. Avez-vous vraiment besoin de prendre en charge votre propre serveur Exchange, votre système RH obsolète ou vos outils d’automatisation des ventes internes ? Valent-ils les efforts de votre équipe ou les dépenses d’exploitation que vous engagez ? Dans le cas contraire, épargnez-vous bien des ennuis en souscrivant à une solution de vente, de RH, de productivité ou autre solution appropriée. Laissez des tiers faire le gros du travail. Vous obtiendrez des gains évidents et rapides avec le SaaS.
Ensuite, vous devrez évaluer vos applications restantes et décider lesquelles vous déplacerez vers le cloud, lesquelles vous refactoriserez pour le cloud et lesquelles conserveront telles quelles.
Posez-vous les questions suivantes :
- Si nous migrons l'application X, combien de choses seront cassées ?
- Où sont les magasins de données ?
- Quelles sont les dépendances ?
- Quels services réseau utilisent-ils ?
- Quelles applications nécessitent des solutions de contournement aux procédures et protocoles normaux pour fonctionner ?
Vous aurez des réponses à ces questions pour bon nombre de vos applications. Pour d’autres, vous ne connaîtrez peut-être pas les réponses tant que vous n’aurez pas réellement essayé de les déplacer. Plus le risque de casse est grand et plus les dépendances sont complexes et peu connues, plus vous avez de chances de conserver une application là où elle est.
Au fur et à mesure que vous cartographiez ces dépendances, documentez-les. Cela sera utile même si seulement quelques-unes de vos applications finissent dans le cloud.
Examinez vos politiques de livraison d’applications et recherchez des opportunités de standardisation et d’automatisation. Vous devez disposer d'un nombre limité de stratégies d'équilibrage de charge standard (par exemple 10) plutôt que de configurations personnalisées pour chaque application. Déterminez des niveaux de stockage standardisés. Définir des services réseau standardisés. Parlez à vos développeurs des avantages de la standardisation et obtenez leur engagement. Créez des modèles pour les aider à déployer les choses rapidement et facilement.
Demandez-vous qui va accéder à chaque application et d’où. Vous devez planifier le comportement des utilisateurs, la connectivité et la bande passante appropriée. De nombreuses applications que vous souhaitez migrer vers le cloud, qu’elles soient privées ou publiques, doivent être plus facilement accessibles depuis n’importe où. Les déplacer vers le cloud exercera moins de pression sur l’infrastructure.
Il existe également des problèmes d’authentification et de sécurité ; la plupart des entreprises ont traditionnellement utilisé les contrôles réseau plutôt que les contrôles d’application pour déterminer l’accès. Dans un cloud public, vous devrez peut-être adopter de nouvelles technologies de gestion des identités et des accès que vous n’aviez pas auparavant.
Lors de la migration vers le cloud, l’architecture sera différente car les constructions ne sont pas statiques. Pour les applications monolithiques comme les bases de données, les mécanismes qui étaient auparavant liés à des adresses IP spécifiques ou à d’autres constructions constantes ne fonctionneront pas dans le cloud. Vous aurez peut-être besoin d’équilibreurs de charge ou de proxys supplémentaires qui contribueront à assurer la cohérence dans un environnement en constante évolution. Créez des points de contrôle supplémentaires afin de garantir que tout le monde puisse accéder à vos applications de manière cohérente et sans interruption.
C'est un sujet difficile. Comme nous l’avons dit au début, les architectures informatiques sont compliquées.
Même si cela n’est pas facile, cela en vaut la peine, ne serait-ce que pour les économies de coûts (OpEx et CapEx) et l’évolutivité. Certaines entreprises ont réalisé des économies considérables simplement en se préparant au cloud. En évaluant vos inventaires d’applications existants, en analysant les dépendances, en documentant tout et en standardisant et en simplifiant autant que possible, vous serez dans la position idéale pour décider quoi déplacer et comment le faire.