Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
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 l'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 refactorisant 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 les microservices : intégrez les microservices nouvellement créés dans une architecture de microservices en utilisant AWS des services sans serveur.
-
Activez la persistance des données pour les microservices : encouragez la persistance polyglotte
entre 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 anciens.
-
Les projets Greenfield impliquent la création d'un système à partir de zéro pour un environnement totalement nouveau, sans aucun code existant.
Pour les projets de friche industrielle, 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 commencent par des monolithes conçus pour un cas d'utilisation professionnel spécifique. Si l'architecture du monolithe n'impose pas de conception modulaire, un monolithe peut rester un choix valable pour les applications dont les responsabilités ne sont pas clairement définies dans les limites d'une connaissance bien établie du 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 que le couplage serré ou l'absence de structure interne.
Bien qu'un monolithe puisse être une option valable dans 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 entraîne 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 pour ajouter 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 publication de grande envergure, ce qui augmente le fardeau de la collaboration et du 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 augmente.
Pour éviter cela, vous pouvez utiliser des modèles de décomposition pour décomposer les 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 continus (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 utilisés pour décomposer les monolithes, et décrit les avantages et les inconvénients de chacun d'entre eux :
Le guide fait partie d'une série de contenus qui couvre l'approche de modernisation des applications recommandée par AWS. La série inclut également :
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.
-
Ajustements rapides aux fluctuations de la demande commerciale sans interrompre les activités de base, telles que la haute évolutivité, la résilience améliorée, la continuité des livraisons et l'isolation des défaillances.
-
Innovation plus rapide, car chaque microservice peut être testé et déployé individuellement.
