Implémenter votre projet de microservices (partie 3)
Dans cette série de 6 articles sur le développement d’applications de microservices, nous fournissons un contexte pour définir un projet pilote cloud qui correspond le mieux aux besoins actuels et prépare une décision d’adoption cloud à long terme.
Dans la 3e partie, nous vous proposons une méthode pour mettre en œuvre vos propres projets de microservices.
Évolution d’une application existante
Nous allons maintenant approfondir la manière de tracer la voie à des parcours de développement d’applications de microservices à différentes échelles, en vue de passer éventuellement à des transformations à plus grande échelle d’applications existantes.
Bien que la création de microservices sans application préalable soit pertinente ou importante, nous sommes d’accord sur une approche « monolithique » lors de la création de microservices. En bref, cela signifie que vous créez votre application de toutes les manières possibles pour valider votre idée. Ensuite, vous appliquez les principes de cette série de blogs pour dimensionner et faire évoluer votre monolithe initial en un projet de microservice. Il n’y a aucune valeur dans la création de microservices purement architecturaux qui n’offrent pas de valeur à l’entreprise.
Il existe trois domaines à comprendre pour mettre en œuvre un projet de microservices réussi : votre entreprise, votre culture et vos compétences, et votre technologie.
Comprendre et définir les besoins de votre entreprise
Pourquoi envisagez-vous les microservices ? Pour de nombreuses entreprises, des pratiques de développement de logiciels et d’opérations plus efficaces sont nécessaires pour apporter de la valeur à l’entreprise plus rapidement et offrir une meilleure expérience utilisateur.
Avant de pouvoir comprendre l’impact d’un projet de microservices sur vos applications et votre infrastructure existantes, vous devez comprendre quels secteurs de votre entreprise évoluent trop lentement pour produire des résultats satisfaisants. Dans de nombreux cas, les systèmes d’engagement (SOE) de l’organisation sont à l’origine de ce ralentissement. Ces systèmes sont disponibles via de nombreux canaux : Web, mobiles, API, etc. La lenteur est la principale raison de passer à une architecture basée sur les microservices.
Avant de pouvoir adopter une approche orientée vers les microservices, vous et les parties prenantes de votre entreprise devez savoir ce qui n’est pas mis sur le marché assez rapidement. Quels éléments de l’application ont besoin d’améliorations et de modifications pour les rendre plus rapides ? Pour répondre à cette question, il faut savoir quelles parties du monolithe existant devraient être ciblées pour l’évolution du microservice.
Utilisez des flux d’expérience utilisateur ou des diagrammes d’architecture pour aider l’équipe à tailler rapidement des sections du monolithe existant via des annotations de type carte thermique. Par exemple, en utilisant l’échelle rouge-jaune-vert pour la priorité des points de friction, voici une archive d’application Web pour une devanture de magasin :
À ce stade, sans être exhaustifs et avec une ouverture itérative, les principaux objectifs de l’évaluation sont les suivants :
Identifier les fonctions métier distinctes que votre monolithique fournit
Comprendre la vitesse et la complexité relatives nécessaires pour modifier ces fonctions métier
Comprendre le désir du propriétaire de l’entreprise de voir des cycles de commentaires plus rapides pour ces fonctions métier spécifiques
Comprendre votre culture et vos compétences
Bien que cela ne soit pas spécifique aux architectures basées sur les microservices, une compréhension approfondie des équipes, de la culture et du niveau de compétences d’une entreprise est critique pour une transformation numérique réussie.
Généralement, dans les monolithes d’ingénierie, la plupart des entreprises sont intégrées dans des silos, avec des équipes participant en fonction des besoins tout au long du cycle de vie du développement logiciel. Cela crée souvent des limites bien définies, avec des rôles et des responsabilités restreints le long de ces limites.
Les architectures de microservices ne peuvent réussir que si les équipes ont le pouvoir de s’approprier le cycle de vie complet du développement logiciel et des opérations. La constitution d’équipes interfonctionnelles représentant tous les rôles et toutes les responsabilités est essentielle dans la mise en œuvre d’architectures basées sur des microservices. Chacun, de la conception au développement, en passant par les opérations et le propriétaire de l’entreprise, travaille en étroite collaboration et se trouve souvent au même endroit.
Étant donné que chaque partie prenante est représentée dans l’équipe (conception, développement et opérations), le travail peut avancer plus rapidement, plus efficacement et avec un accent clair mis sur l’amélioration de l’expérience utilisateur en vue d’atteindre les objectifs commerciaux.
Une équipe interfonctionnelle favorise également le développement rapide des compétences individuelles au sein de l’équipe. Lorsqu’une équipe est propriétaire de tout ce dont le microservice est responsable, de la conception aux opérations en passant par les données d’exécution, aucun membre de l’équipe n’effectue la moindre tâche. Souvent, les ingénieurs front end développent des compétences en matière d’administration de bases de données, tandis que les membres de l’équipe orientés vers les opérations en savent plus sur les différences entre les cadres des exigences d’une interface utilisateur. En élargissant les compétences de cette façon, l’ensemble de l’entreprise peut réussir avec les microservices, car il est beaucoup plus facile de constituer de nouvelles équipes composées de membres complets, au lieu de chercher constamment des spécialistes pour occuper des rôles très spécifiques.
Comprendre la technologie
Si vous ne résolvez pas le problème métier et ne résolvez pas la culture et les compétences de votre équipe, vous ne serez pas en mesure d’implémenter efficacement la technologie des microservices et vous conserverez les mêmes processus et structures en place.
L’analyse correcte des piles technologiques existantes varie considérablement d’une entreprise à l’autre, mais l’approche simplifiée que nous décrivons permet de garantir le succès initial et durable de vos projets de microservices. Commencer petit et définir des réussites itératives et progressives est une approche beaucoup plus réalisable et fructueuse qu’une approche tape-à-l’œil, qui consiste à tout transformer d’un seul coup.
La première phase pour comprendre votre technologie consiste à identifier les services à granularité grossière qui se trouvent dans le monolithe existant. L’identification de ces services à granularité grossière vous aide à comprendre la complexité des structures de données, le niveau de couplage entre les composants actuels, les équipes responsables de ces nouveaux services à granularité grossière, etc. Un examen réussi des services vous permet de comprendre clairement les limites, à l’intérieur d’un service donné et entre les services.
Une fois que vous avez identifié les services à granularité grossière, vous devez créer un plan pour faire évoluer ces services à granularité grossière en microservices. D’après vos travaux précédents, ces microservices doivent tous travailler avec des données similaires, posséder leurs « propres » données et comprendre quelles données ils doivent lire d’où et écrire dans d’autres services. À partir de là, vous pouvez identifier et mettre en œuvre la résilience, l’évolutivité et l’agilité des microservices à granularité fine individuels.
Les API et les microservices font partie d’un ensemble plus vaste. Une fois que vous aurez une meilleure compréhension de votre microservice à granularité fine, vous aurez également une meilleure compréhension de vos interfaces, de celles qui sont sur le chemin critique, de celles qui sont optionnelles et de celles dont vous n’avez plus besoin. Si vous ne pouvez pas mapper une interface ou une API existante à l’un de vos microservices à granularité grossière ou fine, vous pouvez très probablement vous en passer.
Dimensionner l’effort en matière de microservices
La compréhension de l’activité, de la structure de l’équipe et de la technologie permet à vos équipes et à l’entreprise dans son ensemble de comprendre l’intégralité de l’évolution des microservices d’un monolithe donné, qu’il s’agisse d’une validation de concept, d’un projet pilote ou d’une évolution à grande échelle.
Une fois le travail d’analyse et de planification terminé, les étapes suivantes consistent à définir les délais, les vitesses de livraison et les résultats.
Dans le prochain article, nous examinerons les modèles de développement et d’opérations que vous pouvez appliquer pour entreprendre une transformation des microservices.
À partir de là :
Pour moderniser et remanier une application monolithique, consultez la progression architecturale détaillée.
Roland Barcia (ingénieur émérite IBM/directeur technique) et Rick Osowski (membre principal du personnel technique) ont collaboré avec Kyle sur cet article.