Les migrations vers le cloud à vitesse élevée, qu’elles soient motivées par des événements qui changent le monde ou simplement par une sortie de centre de données mal synchronisée, nécessitent un niveau élevé d’attention et de soin. Dans cet article, l’architecte cloud Tim Perry partage quelques bonnes pratiques pour accélérer la migration vers le cloud.
J’ai travaillé avec diverses organisations de plusieurs secteurs lors de la planification et de l’exécution de leurs migrations vers le cloud. Bien que chaque migration vers le cloud apporte des obstacles et des défis uniques, les migrations à grande vitesse, souvent déclenchées par nécessité plutôt que par long terme stratégie transformationnelle sont particulièrement difficiles. Lisez la suite pour connaître les meilleures pratiques que j’ai apprises pour cultiver une migration réussie vers le cloud à grande vitesse – et en outre, bénéficier d’une approche accélérée de l’adoption du cloud, comme notre expérience de migration vers le cloud Accédez au Cloud en 50 jours en partant de zéro avoir les bonnes personnes impliquées dès le début de tout projet sera essentiel au succès. Vous avez besoin de l’adhésion des parties prenantes concernées et d’une équipe engagée, habilitée et compétente pour exécuter.
Bien que ce point soit fondamental, dans les migrations à grande vitesse, cela devienne primordial car les bonnes personnes développeront finalement une “confiance cérébrale” à partir de la migration. Cela compléterait le centre d’excellence cloud traditionnel (CCoE) qui fournit normalement des conseils stratégiques pour l’adoption du cloud. Cette confiance cérébrale comprend des membres clés de l’équipe de livraison tels que les chefs de projet, les responsables de la prestation de services, les ingénieurs cloud et les architectes. Ce pool de connaissances sera déterminant tout au long du programme.
En réalité, des absences se produiront : de longues vacances, des congés de maternité ou lors des départs d’employés, par exemple. L’objectif est d’impliquer autant que possible les principales parties prenantes et les décideurs sans créer trop de frictions ni ralentir le rythme de la prestation.
2. Priorisez une responsabilité claire
dans les migrations précédentes, nous avons observé que les responsabilités peuvent parfois devenir obscures. Il s’agit généralement d’un sous-produit de la réorganisation ou du changement de rôle qui laisse des lacunes dans la chaîne de communication.
dans les migrations à grande vitesse, très souvent, les équipes de conception et d’ingénierie rencontrent un problème et doivent faire pivoter la solution. Ces modifications doivent être communiquées par les canaux appropriés et les approbations doivent être demandées.
Dans ces cas, il est important que le processus d’approbation soit simplifié et aussi facile et clair que possible. Cela permet aux équipes de résoudre le problème rapidement et de passer à d’autres éléments du backlog.
un manque de responsabilité claire ou de propriété des applications peut saboter une migration. Souvent, un propriétaire d’application est nommé mais n’est pas informé ou sensibilisé sur les attentes connexes.
La réussite est un processus qui dépend de la volonté d’une organisation de s’engager dans une culture plus agile et axée sur les résultats qui encourage la collaboration ouverte et la sécurité psychologique. Sans cela en place, les individus ont souvent recours à une prise de décision peu encline à prendre des risques qui anticipe des discussions plus larges et augmente les retards.
3. Créer une infrastructure de migration
Un cadre directeur qui décrit les principes directeurs de la façon dont la migration sera réalisée devrait être mis en place.
Le cadre devrait comprendre :
- Conseils sur les responsabilités identifiées dans tous les domaines, unités commerciales et plates-formes concernés par la migration
- Principes et modèles de conception d’architecture prédéfinis auxquels les applications doivent adhérer lors de la migration vers le cloud qui fonctionne en conjonction avec un cadre de révision d’architecture
- Des seuils clairement définis en ligne avec le modèle de coût du client
- Des orientations clairement définies sur les exigences géopolitiques qui auront une incidence sur la sélection des régions dans le Cloud et les exigences en matière de stockage des données
- Des directives et des attentes claires en matière de conformité et d’exigences réglementaires qui auront un impact sur la migration vers le cloud
- Principales attentes quant aux résultats de l’exécution des charges de travail dans le cloud (telles que les économies attendues ou la génération de revenus supplémentaires grâce au commerce électronique) et contraintes budgétaires (ce qui est alloué à la migration et le délai prévu pour l’achèvement)
4. Établir un cadre de révision de l’architecture
Comme mentionné précédemment, les architectes et les ingénieurs de migration sont parfois bloqués par des comités ou des groupes de révision de la conception car la solution ne répond pas aux exigences x, y et z.
Nous avons vu ces groupes d’intervenants retarder les migrations pour des raisons qui sont souvent techniquement valables. Souvent, selon la gravité du problème, le seul moyen de recours est que l’équipe d’ingénierie fasse remonter le problème au gestionnaire de l’exécution du programme, qui peut à son tour s’aggraver en conséquence.
Nous comprenons et respectons le processus d’escalade concernant ces types de scénarios. Les ninjas du programme ajouteront des contingences à leurs échéanciers et à leurs ressources pour les accommoder.
Cependant, une approche encore meilleure consiste à établir un cadre d’examen de l’architecture convenu pour régir les exigences de la solution.
Idéalement, ce cadre devrait :
- Établir des lignes directrices et des paramètres clairs avec lesquels les équipes de conception et d’ingénierie doivent aligner les solutions. Cela contribue à éviter toute surprise lors de la présentation au groupe d’intervenants pour examen et approbation.
- Simplifiez le flux de travail pour permettre la révision de l’architecture hors connexion
- Appelez à l’approbation automatique de toute conception de migration qui répond aux exigences spécifiques strictes telles que l’absence de données PII ou d’applications à usage interne uniquement.
Un mot d’avertissement : Il n’y a pas de temps pour un examen arbitraire dans une migration à grande vitesse. Trop souvent, nous avons vu des conceptions de solutions mises au sac de sable par des groupes de parties prenantes pour des raisons arbitraires (bien que parfois valides) qui retardent finalement le programme de migration.
Par exemple, nous avons vu un nouvel architecte de sécurité rejoindre le comité d’examen de l’architecture sans briefing ni contexte fourni. Jusqu’à ce que le nouveau membre soit mis au courant des directives directrices du programme, le programme de migration a subi des revers.
5. Cohérence et clarté de la communication
Les dysfonctionnements de la communication entre les membres de l’équipe de livraison entraînent souvent des erreurs et des pertes de temps. Par exemple, si un membre de l’équipe modifie la portée d’une application mais ne parvient pas à alerter le bon ingénieur, le risque d’erreurs potentielles telles que le basculement sur la mauvaise machine virtuelle et la défaillance involontaire de l’entreprise augmente.
Plus probablement, cependant, un ingénieur perdra du temps à construire et à préparer la migration d’un serveur qui a été exclu du champ d’application. Ces types de choses doivent être communiqués au préalable pour éviter de demander “combien de temps prend une migration de serveur ?” après la création d’un plan.
Ces types de situations se produiront inévitablement. Cependant, si elles se produisent trop souvent, les conséquences peuvent être drastiques pour une migration à grande vitesse, où le rythme rapide exige une faible marge d’erreur. Le temps d’ingénierie perdu dans les travaux de correction perturbe fortement un flux de travail de migration étroitement couplé.
6. Outils de gestion de programme unifiés
Pour relever les défis qu’un bureau de gestion de projet (PMO) double peut présenter lors d’une migration critique à grande vitesse, l’utilisation d’un seul outil de gestion de projet partagé peut être inestimable.
cela est apparu clairement lors d’une migration que nous avons effectuée pour une organisation qui utilisait une seule feuille de calcul pour suivre un programme de 300 applications. Le tracker n’était pas largement disponible pour tous les membres de l’équipe de livraison, et il était maintenu par une seule personne. D’autres ont été découragés de le mettre à jour au cas où des changements de rupture seraient apportés. Quelque chose d’aussi simple qu’un nom de serveur mal orthographié aurait pu entraîner la suppression de la formule appliquée de scope.
Heureusement, la même organisation a heureusement imposé l’utilisation de Microsoft Teams pour toutes les communications de migration et sharePoint afin de permettre une meilleure collaboration sur les documents de conception, les runbooks de migration, etc.
7. Les évaluations de portefeuille d’applications ne sont pas la solution be-all-end-all
dans Cloudreach, nous utilisons Cloudamize, notre plate-forme interne d’évaluation et de gestion du cloud, pour effectuer une plongée automatisée dans le portefeuille d’applications d’un client et identifier autant de dépendances que possible.
Bien que cela fournisse un instantané inestimable du portefeuille, en réalité, les organisations ont presque toujours des applications uniques et personnalisées. Aucun outil ne serait capable de détailler chaque dépendance (et encore moins de déterminer l’approche tactique appropriée!).
Dans ces cas, il faut faire preuve de soin et de diligence pour examiner et rassembler manuellement les informations et créer un profil de candidature. Ce processus peut varier. Souvent, si aucune documentation de conception de solution n’est disponible, il faut contacter le propriétaire de l’application pour déterminer le profil de son application.
Comme il s’agit d’une approche qui prend beaucoup de temps, il est important (lorsque cela est possible) d’appeler ces instances et de gérer les attentes en conséquence.
Il s’agit d’un défi particulier lors des migrations à grande vitesse, où la migration d’un nombre x d’applications par sprint est un résultat mesuré par la direction.
Dans ces scénarios, nous travaillons pour aider les clients à comprendre les trois vecteurs de valeur :Bon, Rapide et Bon marché.
La règle de base est que, si vous voulez quelque chose de bon et rapide, alors cela ne peut pas être bon marché. Inversement. si vous voulez quelque chose de bon marché et rapide, alors cela ne peut pas être bon.
Dans la pratique (d’ingénierie), les migrations à grande vitesse se déroulent souvent de l’une des deux manières suivantes :
- Livré à grande vitesse (rapide) avec un coût minimal (bon marché) et entraînera une dette technologique (pas bon)
- Livré à grande vitesse (rapide) avec une dette technologique minimale (bon) et entraînera une augmentation des coûts (pas bon marché)
- Le passage en revue des accords de licence actuels pour confirmer qu’ils sont adaptés à la migration vers le fournisseur de cloud approprié. Par exemple, certaines entreprises ont conclu des contrats de licence personnalisés avec leur fournisseur de logiciels qui peuvent ne pas être facilement transférés vers le cloud.
- Passez en revue les versions actuelles des logiciels pour vous assurer qu’elles sont compatibles avec le fournisseur de cloud approprié. Par exemple, le Real Application Cluster d’Oracle n’est pris en charge sur aucune plate-forme de cloud public, à l’exception de leur propre Oracle Cloud. Les entreprises exécutant cette plate-forme de base de données héritée ont été contraintes de pivoter la conception de la migration, ce qui entraîne des retards et des coûts accrus.
- Dans la mesure du possible, engagez votre spécialiste des licences le plus tôt possible pour déterminer la compatibilité et les coûts potentiels ou, mieux encore, les économies potentielles.
<
/ul>
La plupart des leaders technologiques comprennent cela et tentent de trouver un équilibre entre les deux. Malgré les bonnes intentions, l’adoption d’une approche équilibrée peut entraîner des problèmes imprévus tout au long du programme de prestation.
Une approche équilibrée fait qu’il est difficile pour les décideurs de comprendre où les lignes sont tracées. Par exemple, si une application complexe doit être reconstruite en tant que cloud natif (faible dette technologique, coût élevé) au lieu d’un portage virtuel (dette haute technologie, faible coût), la décision devra évoluer et être révisée (plus de temps perdu).
C’est là qu’un cadre de migration bien conçu peut simplifier ces points de décision et aider à créer un flux plus fluide – un principe majeur des migrations à grande vitesse.
8. Démystification de la cartographie des dépendances
J’ai mentionné plus tôt qu’un élément clé d’une évaluation d’application (automatisée ou manuelle) consiste à cartographier les dépendances d’une application particulière. D’après mon expérience, les dépendances peuvent varier considérablement, d’un simple partage de fichiers à des tâches cron distantes en passant par des packages SSIS ou même des connexions vers et depuis un tiers.
Chaque type nécessite une approche tactique différente lors d’une migration.
Ce n’est pas parce qu’une évaluation automatisée du cloud a détecté quelques dépendances que le travail est terminé. Parfois, en tant qu’architecte, je dois redessiner des composants entiers de l’architecture cible pour la faire fonctionner. D’autres fois, nous pouvons simplement l'”ajouter” à la conception et à la portée.
En fin de compte, l’identification des dépendances est la première étape, mais la façon dont nous les traitons peut finir par faire ou défaire la migration – à la fois du point de vue technique et commercial.
Par exemple, les applications complexes avec une documentation ou une compréhension inadéquate de la part des propriétaires d’applications peuvent finir par s’effondrer sur des chemins de migration difficiles remplis de pivots de conception et d’appels de dépannage, en grande partie parce que les dépendances ne sont pas divulguées ou, pire encore, identifiées à mi-chemin d’une migration.
9. Octroi de licences
L’octroi de licences, comme la mort et les impôts, est quelque chose que nous devons tous gérer. Dans une migration à grande vitesse, il est essentiel de s’assurer que les licences sont toutes liées. Sinon, elles reviendront inévitablement pour emmêler votre projet. Les mesures spécifiques à prendre sont les suivantes :
10. Appliquez les principes CI/CD au programme de migration lui-même
Au fur et à mesure que le programme de migration progresse, assurez-vous de suivre son avancement. Examinez les processus et les outils actuels qui prennent en charge tous les aspects de la livraison du projet \ pour vous assurer qu’ils correspondent toujours à l’objectif.
Des informations précieuses feront surface grâce à un examen constant et à la sollicitation de commentaires des principaux acteurs de la réalisation de projets. Le cadre de migration devrait être un document évolutif. Il doit être alimenté par ces informations exploitables.
La mise en œuvre de modifications pour rationaliser et simplifier le processus positionnera au mieux votre projet de migration à grande vitesse pour réussir.
La migration accélérée vers le cloud peut sembler un défi (et c’est le cas !). Ces meilleures pratiques et leçons apprises devraient vous aider à soutenir et à accélérer vos efforts de migration. Avec les bonnes personnes et les bons processus – et un partenaire de confiance – votre organisation peut en récolter les bénéfices plus tôt que vous ne le pensez.
Notre programme Zero to Cloud in 50 Days vous aide à faire exactement cela – c’est une expérience de migration vers le cloud “sans regrets” avec les meilleures pratiques intégrées. Il comprend des conseils stratégiques, des étapes tactiques, une analyse du coût total de possession, l’accès aux programmes de financement de nos fournisseurs de services cloud – et plus encore.
