Quel que soit le projet de cloudification (nouvelle application, réécriture d’une application existante, simple migration…), l’agilité et la flexibilité qu’apporte le cloud autorisent le droit à l’erreur.
Là où la construction d’une infrastructure on-premises faisait souvent l’objet d’investissements importants, de processus complexes et chronophages, il est aujourd’hui possible de créer, modifier, supprimer des éléments d’infrastructure très simplement, en quelques minutes, avec une incidence financière mineure en cas d’erreur.
Dans ce livre blanc, nous nous penchons sur un cas de figure que bon nombre de sociétés désireuses de se tourner vers le cloud public rencontrent : “Comment migrer une application monolithique hébergée on-premises vers le cloud ?“ Mais aussi, “Peut-on se tourner dans notre cas vers une solution Serverless en connaissance des avantages que cela procure ?” (cf. chapitre 1).
Nous ne sommes pas ici dans un exercice de Lift & Shift (déplacement simple d’une application vers le cloud sans la retoucher) brutal d’un univers IaaS on-premises vers un autre univers IaaS d’un cloud provider, mais bien dans une démarche de réécriture d’une application existante à destination d’une architecture Serverless.
Tout au long de ce chapitre, nous prendrons en exemple un projet de réécriture/migration vers le cloud d’une application B2B d’une société d’assurance-crédit. Cette application permet aux partenaires et aux courtiers de suivre leurs contrats d’assurance et leurs commissions. Sur ce qui va suivre, nous allons nous focaliser sur la migration/réécriture des APIs de cette application.
Étape 1, Identifier les services ?
Cette étape n’est pas propre au monde du cloud ni au Serverless, mais plutôt en lien direct avec la tendance des architectures microservices. En synthèse, il s’agit de découper notre monolithe en x services faiblement couplés entre eux.
Ce type d’architecture offre la possibilité pour une équipe de travailler indépendamment sur un service sans impacter les autres, et sans être impactée par les autres services.
Cela permet d’améliorer la fréquence des mises à jour et le time to market des fonctionnalités à mettre en place. À chacun des services identifiés correspond généralement une ou n APIs exposée(s).
Sur notre projet, les premiers services identifiés ont été :> création d’un contrat d’assurance,
> affichage des limites de remboursement,
> affichage de la situation financière des clients et prospects,
> calcul du taux de risque (client, région, pays),
> affichage des commissions par partenaire,
> suivi des échéances de paiement.
Étape 2, Comment passer d’un système 100% on-premises à un système 100% cloud ?
Deux options sont généralement possibles. Une migration progressive service par service versus une solution big-bang, où l’on switch brutalement entre l’ancien monde et le nouveau. Le choix de l’une ou l’autre solution dépend de multiples facteurs parmi lesquels : le niveau de maturité des équipes, la taille de l’application, les risques liés à l’obsolescence…
L’option de la migration progressive a toutefois plusieurs avantages :
> permettre de délivrer rapidement les premières briques du futur système, et donc rassurer les parties prenantes sur les choix qui sont faits,
> prendre moins de risques qu’une solution big-bang.
Mais aussi une contrainte principale :
> faire vivre les deux systèmes en parallèle durant toute la phase du projet, ce qui nécessite très souvent une mise à jour des données entre l’environnement on-premises et celui sur le cloud.
Cette option de migration est connue sous le nom de Strangler pattern.
Notre projet de migration et de réécriture concerne une centaine d’APIs. Ce nombre important nous a poussé à choisir l’option d’une migration progressive. Pour chaque API, le processus de migration commence par la réécriture de chacune d’elle tout en respectant les 5 piliers du Well-Architected Framework (excellence opérationnelle, sécurité, fiabilité, efficacité des performances et optimisation des coûts), passant par les tests fonctionnels sous Postman et les tests de charge sous Gatling avant la mise en production.
Pour aller plus loin sur le sujet, notre livre blanc est disponible au téléchargement (format PDF interactif). Vous pouvez également consulter le premier chapitre, « Le Serverless quèsaco ? ».