Décomposer des monolithes en microservices

Tabby Ward et Dmitry Gulin, Amazon Web Services (AWS)

Avril 2023 (historique du document)

La migration vers le cloud Amazon Web Services (AWS) présente de nombreux avantages, notamment une agilité technique et commerciale, de nouvelles opportunités de revenus et une réduction des coûts. Pour tirer pleinement parti de ces avantages, vous devez continuellement moderniser les logiciels de votre entreprise en transformant vos applications monolithiques en microservices. Ce processus comprend trois étapes principales :

• Décomposer les monolithes en microservices : utilisez les modèles de décomposition fournis dans ce guide pour décomposer les applications monolithiques en microservices.

• Intégrer des microservices : intégrez les microservices nouvellement créés dans une architecture de microservices à l'aide de servicesAWS sans serveur.

• Activez la persistance des données pour les microservices : favorisez la persistance polyglotte parmi vos microservices en décentralisant les magasins de données.

La modernisation implique généralement deux types de projets :

• Les projets Brownfield impliquent le développement et le déploiement d'un nouveau système logiciel dans le contexte de systèmes existants ou existants.

• Les projets Greenfield impliquent la création d'un système à partir de zéro pour un environnement complètement nouveau, sans aucun code existant.

Pour les projets de sites contaminés, l'une des premières étapes de la modernisation de vos applications consiste à décomposer les monolithes de votre portefeuille en microservices.

La plupart des applications débutent sous la forme de monolithes conçus pour un cas d'utilisation métier spécifique. Si l'architecture du monolithe n'impose pas une conception modulaire, un monolithe peut rester un choix valable pour les applications qui n'ont pas de responsabilités clairement définies dans les limites de connaissances bien établies dans le domaine. La caractéristique centrale d'un monolithe en tant qu'unité de déploiement unique peut également contribuer à atténuer les défauts de conception, tels qu'un couplage serré ou l'absence de structure interne.

Bien qu'un monolithe puisse être une option valable pour certains cas d'utilisation, il n'est généralement pas adapté à une application moderne. Les structures internes mal définies d'un monolithe peuvent compliquer la maintenance du code, ce qui crée une courbe d'apprentissage abrupte pour les nouveaux développeurs et entraîne des coûts de support supplémentaires. Un couplage élevé et une faible cohésion peuvent augmenter considérablement le temps nécessaire à l'ajout de nouvelles fonctionnalités, et il se peut que vous ne puissiez pas adapter les composants individuels en fonction des modèles de trafic. Les monolithes nécessitent également la coordination de plusieurs équipes pour une seule version importante, ce qui augmente la charge de collaboration et de transfert de connaissances. Enfin, vous pouvez constater qu'il devient difficile d'ajouter de nouvelles fonctionnalités ou de créer de nouvelles expériences utilisateur lorsque votre activité ou votre base d'utilisateurs se développe.

Pour éviter cela, vous pouvez utiliser des modèles de décomposition pour décomposer des applications monolithiques, les convertir en plusieurs microservices et les migrer vers une architecture de microservices. Une architecture de microservices structure une application sous la forme d'une série de services faiblement couplés. Les microservices sont conçus pour accélérer le développement de logiciels en permettant des processus de livraison et de déploiement (CI/CD).

Avant de commencer le processus de décomposition, vous devez évaluer les monolithes à décomposer. Veillez à inclure des monolithes présentant des problèmes de fiabilité ou de performance, ou à inclure plusieurs composants dans une architecture étroitement couplée. Nous vous recommandons également de bien comprendre le cas d'utilisation commerciale du monolithe, sa technologie et ses interdépendances avec d'autres applications.

Ce guide s'adresse aux propriétaires d'applications, aux chefs d'entreprise, aux architectes, aux responsables techniques et aux chefs de projet. Il décrit les six modèles natifs du cloud suivants qui sont utilisés pour décomposer les monolithes, et décrit les avantages et les inconvénients de chacun d'entre eux :

• Décomposer par capacité métier

• Décomposer par sous-domaine

• Décomposer par transactions

• Modèle de service par équipe

• Motif de figues Strangler

• Branche par modèle d'abstraction

Le guide fait partie d'une série de contenus qui couvre l'approche de modernisation des applications recommandée parAWS. La série inclut également :

• Stratégie de modernisation des applications dans leAWS cloud

• Approche progressive de la modernisation des applications dans leAWS cloud

• Évaluation de l'état de préparation à la modernisation des applications dans leAWS cloud

• Intégration de microservices à l'aide de servicesAWS sans serveur

• Activation de la persistance des données pour les microservices

Résultats commerciaux ciblés

Vous devez vous attendre aux résultats suivants après avoir décomposé vos monolithes en microservices :

• Une transition efficace de votre application monolithique vers une architecture de microservices.

• Des ajustements rapides à la fluctuation de la demande commerciale sans interrompre les activités principales, telles que la haute évolutivité, l'amélioration de la résilience, la fourniture continue et la détection des défaillances.

• Innovation plus rapide, car chaque microservice peut être testé et déployé individuellement.