Les 6 R de la migration vers le cloud (retirer, conserver, modifier, réhéberger, redéfinir la plate-forme et refactoriser) sont incontournables depuis plusieurs années. Je ne sais pas d’où ils viennent, mais vous les trouverez notés sous une forme ou une autre sur de nombreuses diapositives de travail de migration vers le cloud.
Le facteur pour les 6 R est simple. Nous avons des charges de travail, qui sont généralement des applications et des données couplées qui ne fonctionnent pas sur un cloud, et nous cherchons à les classer dans des catégories concernant ce qui en sera fait à l’avenir, dans le cloud ou non. Voici la brève description des 6 R :
- Retirer : supprimer totalement une œuvre ou la mettre en fin de vie.
- Maintenir : la conserver là où elle se trouve.
- Modifier : recherchez des systèmes SaaS ou d’autres analogues pour la charge de travail.
- Réhébergez : augmentez-le et déplacez-le, ou déplacez-le simplement vers le cloud avec quelques ajustements ou aucun. Passez de Linux sur site à Linux dans le cloud. Je vois cela d’une manière différente de la refactorisation, en ce sens que nous modifions simplement une application pour qu’elle fonctionne bien sur une plate-forme cloud et n’exploitons pas particulièrement les services cloud natifs.
- Re-plateforme : si nous le pouvons Ne découvrons pas d’analogues de plate-forme sur le cloud cible, nous passons à une nouvelle plate-forme, telle que Linux vers Windows. Parfois, de nouvelles bases de données et d’autres plates-formes changent également. Par conséquent, la charge de travail doit être personnalisée pour s’adapter à la nouvelle plate-forme, mais nous n’exploitons pas les services natifs du cloud.
- Refactorisation : personnalisez considérablement (recodez) le travail pour bénéficier des fonctions natives du cloud tels que la sécurité du cloud, la gouvernance, le suivi, l’audit, etc.
Bien sûr, juste pour déconcerter les choses, j’ai en fait vu les 6 R avec des termes différents (tels que « racheter » au lieu de « remplacer ») ou même diverses définitions des Rs. Ne vous moquez pas de moi si ce que vous utilisez ne correspond pas exactement à ce qui précède. Pour nos besoins, cela n’a vraiment pas d’importance.
Lorsque nous examinons des centaines et, dans certains cas, d’innombrables charges de travail, nous forçons ces travaux dans les catégories R. Cela nous permet de nous consacrer à un cours pour ces travaux, du simple et peu coûteux (retirer, conserver et réhéberger) au compliqué et coûteux (re-plateforme et refactoriser).
Mon problème avec les six Rs est qu’ils peuvent restreindre les cours que les architectes cloud peuvent suivre et finir par exiger une charge de travail dans une classification particulière qui ne spécifie pas réellement ce qui doit être fait pour ce travail lors du transfert vers le cloud. Nous pouvons choisir de réhéberger une application, mais que se passe-t-il si cela coûte 100 000 $ pour le faire, alors que beaucoup d’autres approches coûtent 1 000 $ par travail. Qu’est-ce qui est différent ?
Bien que je n’aie vraiment aucun problème avec la retraite, la rétention et le changement, il me semble que de nombreux cours de réhébergement sont très différents, mais on pense toujours à le réhéberger, en ce sens que nous déménageons dans le même plate-forme sur le cloud, mais ne tire généralement pas parti des services natifs du cloud. Je partitionnerais le réhébergement R au moins trois fois de plus. :
- Réhébergement sans changement de code
- Réhébergement avec quelques changements de code
- Réhébergement avec de nombreuses modifications de code (mais sans tirer parti des services natifs du cloud, il est donc pas de refactoring, ou pas de transfert vers une nouvelle plate-forme ou un nouveau système d’exploitation, donc ce n’est pas un re-platforming)
Cela fournit un cours plus précis. Je sais que de nombreuses équipes déplaçant des applications le font actuellement. Je propose généralement des métriques telles que le nombre de lignes de code qui doivent être modifiées et/ou les cycles de filtrage. En les décomposant, il serait plus simple de comprendre le niveau d’effort et donc les dépenses et le temps.
Vous pouvez faire la même chose avec la re-plateforme et la refactorisation. Je les diviserais en un certain nombre de classifications particulières qui clarifieraient mieux ce qui doit être fait pour ces charges de travail afin de mieux cibler le chemin de migration idéal. De même, cela se rapprocherait plus correctement des dépenses et des risques.
Ceci est actuellement en cours dans des usages ponctuels et occasionnels. J’ai en fait décomposé certains emplois jusqu’à 20 R différents, sans toujours imposer la directive selon laquelle la classification doit commencer par un R. D’autres font de même, peut-être même vous.
Est-ce que je fais des choses plus compliquées et peut-être plus difficiles à comprendre ? Vous pariez que je le suis. Néanmoins, l’idée n’est pas d’inclure plus de travail pour classer les charges de travail déplacées vers le cloud, il s’agit de faire une bien meilleure tâche en comprenant les dépenses et les risques réels de faire fonctionner la migration du premier coup.
Toute l’actualité en temps réel, est sur L’Entrepreneur
