samedi, 16 octobre 2021

N’arrêtez pas votre migration !

Vous préparez une migration d’application ? Vous déplacez peut-être votre application sur site vers le cloud ou votre application monolithique vers une architecture orientée services ou microservices.

Les migrations telles que celles-ci sont des engagements. Dédicaces du temps. Dédicaces de ressources. Dévouement de l’état d’esprit et de l’énergie commerciale.

Les migrations sont difficiles à gérer.

Les migrations peuvent impliquer des changements longs et développés, et normalement, l’effort dépensé ne correspond pas directement à un bénéfice reconnu. Typiquement, l’avantage vient beaucoup plus tard que l’investissement. Souvent, les choses empirent même avant de s’améliorer.

Il est tentant de souhaiter arrêter la migration plus tôt.

Qui voudrait faire ça ? Cela semble fou, mais cela se produit. Passer d’une architecture monolithique à une architecture de service, mais s’arrêter peu de temps après le début de la migration, laisse l’application dans un état pire qu’avant le début de la migration.

Alors, comment éviter la tentation d’arrêter une migration dans ses traces ? Eh bien, il s’agit de gérer les attentes et de comprendre le véritable retour sur investissement.

La vallée de la douleur

Lorsque nous commençons une migration importante, en particulier une migration complexe telle en tant que monolithe vers la migration des microservices, nous avons certaines attentes quant aux avantages que nous verrons finalement. Nous prévoyons que les avantages sont fonction de l’effort et du temps que nous consacrons à cette migration. Nous calculons que le ROI (retour sur investissement) rendra l’effort de la migration gratifiant.

Cela finit par être une vue simpliste pour identifier la valeur et les avantages de la migration. Une simple estimation du retour sur investissement ne saisit pas suffisamment notre compréhension de la façon dont nos efforts deviendront des avantages. Normalement, nous pensons que les avantages et l’investissement financier se joueront uniformément avec le temps, comme le montre la figure 1.

IDG

Figure 1. L’effort attendu par rapport à l’investissement semble simple.

Comme le temps passe et nous continuons notre investissement financier dans la migration, nous nous attendons à ce que les avantages que nous recevons, qu’ils soient réels ou visuels, continueront d’augmenter. Plus nous consacrons d’efforts et de temps, plus nous recevons d’avantages. C’est du moins ce que nous croyons.

En réalité, ce modèle optimiste n’est pas représentatif du fonctionnement typique de la migration. La relation entre l’investissement et l’avantage sera souvent beaucoup plus compliquée et ressemblera davantage à la figure 2.

IDG

Figure 2. L’effort réel par rapport à l’investissement financier n’est pas si simple.

Ici, l’investissement financier préalable semble peu avantageux. En fait, nous pouvons voir une régression des avantages à mesure que les choses empirent au début. Ce n’est qu’avec le temps que les avantages réels commenceront à apparaître.

Prenons un exemple. Imaginez que vous déplacez un monolithe vers une architecture orientée services. Initialement, lorsque vous commencez à modifier des parties du monolithe en services, vous risquez de constater des performances réduites. La complexité de l’application augmente puisque votre application comprend beaucoup plus de pièces mobiles. Vous continuez à ajouter des services plus spécifiques à votre application, mais les restes du monolithe existent toujours et sont fortement associés à la fonction de l’application. Cette complexité peut poser des problèmes de fiabilité ; cela peut causer des problèmes de mise à l’échelle ; il peut développer d’autres problèmes imprévus.

En termes simples, votre application peut être encore pire qu’elle ne l’était avant le début de la migration. Il existe de nombreuses raisons pour lesquelles cela se produit :

  • Votre code reste dans un état provisoire, avec une dette technique incluse liée à la migration.
  • Votre code s’exécute plus lentement en raison du fait que certains codes ont été mis à jour et d’autres non.
  • Votre code est plus difficile à comprendre car certains codes utilisent l’ancien paradigme et d’autres le tout nouveau paradigme.

Le code est, franchement, un gâchis.

Au fur et à mesure que le temps passe, vous sortez de ce point bas et les avantages de l’effort de migration commencent à se faire sentir. Vos avantages se multiplient. Vous commencerez à voir un retour sur vos efforts à mesure que la création de services devient plus simple et prend plus de performances du monolithe. La croissance des avantages va progressivement s’accélérer. Enfin, vous verrez la valeur réelle de la migration.

Pour voir ces avantages, vous devez traverser les points bas des premiers jours de la migration. Il faut traverser ce que j’appelle la Vallée de l’Inconfort.

Il y a une forte propension à vouloir arrêter la migration dans cette vallée. Vous avez effectivement investi dans la migration et vous n’avez vu aucun avantage. Au lieu de cela, les choses sont en fait devenues encore pires qu’avant.

Mais n’abandonnez pas ici. N’arrêtez pas la migration à ce stade. Si vous vous en tenez à la migration un peu plus longtemps, vous commencerez à en voir les avantages. En fin de compte, vous arriverez au point où les bénéfices augmentent plus rapidement que les efforts que vous fournissez.

IDG

Figure 3. L’incitation à s’arrêter tôt est forte.

Tombant dans ce piège

J’ai traversé de nombreuses migrations. Pratiquement tous ont cette vallée. Malheureusement, les entreprises tombent dans le piège d’offrir à ce point bas et en subissent les répercussions.

Une entreprise majeure avec laquelle j’ai traité a déserté sa migration monolithique au pire moment possible – tout au fond de la vallée . Ce faisant, ils ont simplement « déclaré victoire ». Il n’y a pas eu de victoire pour eux.

Ils ont informé tous ceux qui travaillaient sur le projet qu’ils avaient tous « assez découvert » de l’effort de migration désagréable : « Nous savons maintenant ce qui est associé à l’exécution de cette migration, nous pouvons donc arrêter ici et peut-être choisir à nouveau la migration plus tard. »

L’entreprise voulait revenir à faire du « vrai travail » et arrêter d’acheter la migration. Ils ont conclu la déclaration en informant tout le monde : « Cet exercice a été une expérience précieuse, ne croyez-vous pas ? Oui, c’était une expérience importante, mais à quel prix ?

Ce que l’entreprise avait réellement développé était une base de code intenable. Ils avaient construit un certain nombre de services qui étaient au sens figuré boulonnés sur le côté du monolithe restant. Pourtant, le monolithe était toujours là et toujours aussi difficile à gérer. Leur code était un gâchis, et ils ont connu les problèmes causés par ce gâchis pendant plusieurs années.

Cette décision a considérablement réduit la capacité de l’entreprise à produire de nouvelles fonctions pendant un certain temps. Le moral au sein du groupe d’ingénierie a atteint un niveau record et l’entreprise a perdu de nombreux excellents ingénieurs. Ils ont même produit de graves problèmes d’accessibilité qui ont affecté l’entière satisfaction des clients. Ce n’était pas un environnement de travail agréable à l’époque.

La leçon de cette histoire est la suivante : la relation entre les avantages et l’effort n’est pas directe. Il y aura des moments au cours de la migration où les choses sembleront empirer plutôt que s’améliorer. Mais n’abandonnez pas. Il y aura une lumière au bout du tunnel, et les avantages commenceront à apparaître. Les avantages seront plus que rentables à long terme.

Avant de commencer la migration, comprenez les coûts et les avantages. Plus important encore, comprenez quand vous devez payer les coûts et quand vous verrez les avantages. Ne vous arrêtez pas lorsque les dépenses commencent à se construire. Si vous continuez à bouger, les avantages finiront par apparaître.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici