Microservices et architecture monolithique

Lorsque l'architecture monolithique devient trop imposante, il est peut-être temps de passer aux microservices

Portrait de Chandler Harris
Chandler Harris

Marketing Strategist et Writer


Une app monolithique est conçue comme une seule unité unifiée, tandis qu'une architecture de microservices est composée d'un ensemble de services plus petits et déployables indépendamment. Quelle solution pour vos besoins ? Cela dépend de plusieurs facteurs.

En 2009, Netflix a rencontré des difficultés croissantes. Son infrastructure ne pouvait pas répondre à la demande pour ses services de streaming vidéo en pleine croissance. La société a décidé de migrer son infrastructure informatique depuis ses data centers privés vers un cloud public et de remplacer son architecture monolithique par une architecture de microservices. Le hic ? Le terme « microservices » n'existait pas, et la structure était méconnue.

Netflix est devenue l'une des premières entreprises de premier plan à réussir sa migration en passant d'une architecture monolithique à une architecture de microservices basée sur le cloud. Elle a remporté le prix 2015 JAX Special Jury Award, en partie grâce à cette nouvelle infrastructure qui a internalisé DevOps. Aujourd'hui, Netflix compte plus d'un millier de microservices qui gèrent et prennent en charge des parties distinctes de la plateforme, tandis que ses ingénieurs déploient du code fréquemment, parfois des milliers de fois par jour.

Netflix a été l'une des pionnières dans la transition depuis une architecture monolithique vers une architecture de microservices. Un phénomène de plus en plus courant aujourd'hui.

Qu'est-ce qu'une architecture monolithique ?


Une architecture monolithique est un modèle traditionnel de programme de développement, conçu comme une unité unifiée autonome et indépendante d'autres apps. Le terme « monolithe » est souvent attribué à un objet volumineux et froid, ce qui représente assez bien une architecture monolithique pour la conception de logiciels. Une architecture monolithique constitue un vaste réseau informatique unique doté d'une base de code qui associe toutes les préoccupations de l'entreprise. Pour apporter un changement à ce type d'app, il faut mettre à jour l'ensemble de la stack en accédant à la base de code, puis en créant et en déployant une version mise à jour de l'interface côté service. Les mises à jour sont alors contraignantes et chronophages.

Les monolithes peuvent être pratiques durant les premières phases d'un projet pour faciliter la charge cognitive liée à la gestion du code et au déploiement. Cela permet de livrer tout le contenu du monolithe à la fois.

Image d'une architecture monolithique
Icône de build de code
Contenu connexe

Comment développer des microservices

Icône de trois cercles
DÉCOUVRIR LA SOLUTION

Gérez vos composants grâce à Compass

Avantages d'une architecture monolithique


Les organisations peuvent profiter d'une architecture monolithique ou de microservices, en fonction de différents facteurs. Le principal avantage d'une architecture monolithique ? Elle est rapide à développer. L'app étant basée sur une seule base de code, elle est simple à prendre en main.

Citons quelques avantages d'une architecture monolithique :

Déploiement facile : un seul fichier exécutable ou répertoire facilite le déploiement.

Développement : lorsqu'une app est conçue avec une seule base de code, elle est plus facile à développer.

Performances : dans une base de code et un dépôt centralisés, une API peut souvent remplir la même fonction que celles assurées par de nombreuses API avec les microservices.

Tests simplifiés : étant donné qu'une app monolithique est une unité centralisée, les tests de bout en bout peuvent être effectués plus rapidement qu'avec une app distribuée.

Débogage facile : comme l'ensemble du code est centralisé, il est plus facile de suivre une demande et de trouver un ticket.

Inconvénients d'une architecture monolithique


Comme dans le cas de Netflix, les apps monolithiques peuvent être très efficaces jusqu'à ce qu'elles soient trop volumineuses et que la mise à l'échelle se complique. Apporter un petit changement à une seule fonction nécessite de compiler et de tester l'ensemble de la plateforme, ce qui va à l'encontre de l'approche Agile privilégiée par les développeurs d'aujourd'hui.

Citons quelques inconvénients d'une architecture monolithique :

Vitesse de développement plus lente : une app monolithique volumineuse complexifie et ralentit le développement.

Évolutivité : vous ne pouvez pas mettre à l'échelle des composants individuels.

Fiabilité : si une erreur survient dans un module, elle peut affecter la disponibilité de l'ensemble de l'app.

Obstacle à l'adoption de la technologie : les changements apportés au framework ou au langage affectent l'ensemble de l'app, ce qui les rend souvent coûteux et chronophages.

Manque de flexibilité : un monolithe est limité par les technologies déjà utilisées en son sein.

Déploiement : un changement mineur apporté à une app monolithique nécessite le redéploiement de l'ensemble du monolithe.

Qu'est-ce que les microservices ?


Une architecture de microservices, également appelée simplement microservices, est une méthode architecturale qui repose sur une série de services déployables indépendamment. Ces services ont leur propre logique métier et leur propre base de données avec un objectif précis. La mise à jour, les tests, le déploiement et la mise à l'échelle ont lieu dans chaque service. Les microservices dissocient les principales préoccupations spécifiques au domaine d'activité en bases de code indépendantes et distinctes. Ils ne réduisent pas la complexité, mais la rendent visible et plus facile à gérer en séparant les tâches en processus plus petits qui fonctionnent indépendamment les uns des autres et contribuent à l'ensemble.

Les microservices vont souvent de pair avec DevOps, car ils constituent la base des pratiques de livraison continue qui permettent aux équipes de s'adapter rapidement aux exigences des utilisateurs.

Image d'une architecture de microservices

Transition d'Atlassian vers les microservices


Atlassian a opté pour les microservices en 2018 après avoir fait face à des difficultés croissantes avec Jira et Confluence. Nous avons constaté que nos architectures monolithiques à locataire unique qui étaient exécutées sur site ne seraient pas en mesure de s'adapter aux besoins futurs.

Nous avons décidé de réorganiser Jira et Confluence, et de migrer depuis un système monolithique à locataire unique avec état vers des apps cloud multilocataires sans état hébergées par Amazon Web Services (AWS). Nous les décomposerions au fil du temps en microservices. Le projet a été baptisé Vertigo après qu'un ingénieur en chef a déclaré : « J'adore l'idée, mais elle me donne le vertige ». Il s'agissait de notre plus grand projet d'infrastructure à ce jour. Il a fallu deux ans pour achever la transition vers AWS, avec la migration de plus de 100 000 clients en un peu plus de 10 mois, sans interruption de service. Nous nous sommes également engagés à décomposer les services en microservices.

Avantages des microservices


Les microservices ne sont en aucun cas une solution miracle, mais ils résolvent un certain nombre de problèmes pour les logiciels et les entreprises en pleine croissance. Étant donné qu'une architecture de microservices se compose d'unités qui s'exécutent indépendamment, chaque service peut être développé, mis à jour, déployé et mis à l'échelle sans affecter les autres services. Les mises à jour logicielles peuvent être effectuées plus fréquemment, avec une fiabilité, une disponibilité et des performances améliorées. Nous sommes passés de mises à jour une fois par semaine à deux ou trois fois par jour.

À mesure de notre développement, les microservices nous permettent de faire évoluer les équipes et les sites géographiques de manière plus fiable en nous répartissant selon les lignes de propriété des services. Avant de lancer Vertigo, Atlassian possédait cinq centres de développement distincts à travers le monde. Ces équipes distribuées étaient limitées par un monolithe centralisé, et nous devions les soutenir de manière autonome. Les microservices nous aident à cet égard.

Les avantages de Vertigo ? Une accélération du déploiement, une reprise d'activité, une réduction des coûts et des performances accrues. Cela nous permet d'atteindre notre objectif plus rapidement, tout en apportant une plus grande valeur ajoutée aux clients en cours de route.

En outre, plus généralement, les microservices facilitent la mise à jour du code pour les équipes et accélèrent les cycles de livraison grâce à l'intégration continue et à la livraison continue (CI/CD). Les équipes peuvent tester le code et revenir en arrière en cas de problème.

Voyons brièvement les avantages des microservices :

Agilité : promouvoir des méthodes de travail Agile avec de petites équipes qui déploient fréquemment.

Évolutivité flexible : si un microservice atteint sa capacité de charge, de nouvelles instances de ce service peuvent être rapidement déployées sur le cluster attenant afin de réduire la pression. Nous adoptons désormais une solution multilocataire et sans état avec des clients répartis sur plusieurs instances. Nous pouvons prendre en charge des instances bien plus vastes.

Déploiement continu : nos cycles de livraison sont désormais fréquents et plus rapides. Auparavant, nous réalisions des mises à jour une fois par semaine. Maintenant, nous sommes passés à un rythme de deux ou trois fois par jour.

Facilité d'administration et de test : les équipes peuvent tester de nouvelles fonctionnalités et revenir en arrière en cas de problème. Cela facilite la mise à jour du code et accélère la commercialisation des nouvelles fonctionnalités. De plus, il est facile d'isoler et de corriger les pannes ainsi que les bugs des services individuels.

Déploiement indépendant : les microservices étant des unités individuelles, ils permettent de déployer indépendamment des fonctionnalités individuelles de manière rapide et facile.

Flexibilité technologique : les architectures de microservices permettent aux équipes de sélectionner les outils souhaités.

Fiabilité élevée : vous pouvez déployer des changements pour un service spécifique, sans risquer de paralyser l'ensemble de l'app.

Équipes satisfaites : les équipes Atlassian qui travaillent avec des microservices sont beaucoup plus satisfaites, car elles sont plus autonomes et peuvent créer et déployer elles-mêmes sans attendre l'approbation d'une pull request pendant des semaines.

Inconvénients des microservices


Lorsque nous sommes passés d'un petit nombre de bases de code monolithiques à de nombreux autres systèmes et services distribués qui alimentent nos produits, nous avons dû faire face à une complexité inattendue. Au début, nous avons eu du mal à ajouter de nouvelles capacités avec la même vélocité et la même confiance que par le passé. Les microservices peuvent accroître la complexité, entraînant ainsi un développement tentaculaire ou une croissance rapide et non gérée. Il peut s'avérer difficile de déterminer comment les différents composants sont liés les uns aux autres, à qui appartient un composant logiciel spécifique ou comment éviter d'interférer avec des composants dépendants.

Avec Vertigo, nous avons créé une fonctionnalité commune qui alimenterait nos produits existants et les futurs produits que nous acquerrons et concevrons. Si vous êtes une société proposant un produit unique, vous n'avez probablement pas besoin de microservices.

Citons quelques inconvénients des microservices :

Développement tentaculaire : les microservices ajoutent de la complexité par rapport à une architecture monolithique, étant donné que vous avez plus de services dans un plus grand nombre d'emplacements créés par plusieurs équipes. Si cette multiplication n'est pas bien gérée, elle freinera le développement et dégradera les performances opérationnelles.

Coûts d'infrastructure exponentiels : chaque nouveau microservice peut impliquer ses propres coûts pour la suite de tests, les playbooks de déploiement, l'infrastructure d'hébergement, les outils de surveillance, et bien plus encore.

Frais organisationnels supplémentaires : les équipes doivent ajouter un autre niveau de communication et de collaboration pour coordonner les mises à jour et les interfaces.

Défis de débogage : chaque microservice possède son propre ensemble de journaux, ce qui complique le débogage. De plus, un seul processus métier peut s'exécuter sur plusieurs machines, ce qui complique encore le processus.

Manque de standardisation : l'absence de plateforme commune peut entraîner une prolifération des langages, des normes de journalisation et de la surveillance.

Manque de responsabilité claire : lorsque de nouveaux services sont lancés, le nombre d'équipes les exécutant augmente lui aussi. Au fil du temps, il devient difficile de connaître les services disponibles et de savoir qui contacter pour obtenir de l'aide.

Image comparant les architectures monolithiques et de microservices

Conseils d'Atlassian pour migrer depuis une architecture monolithique vers une architecture de microservices


De nombreux projets commencent d'abord en tant que monolithe, puis évoluent vers une architecture de microservices. Au fur et à mesure que de nouvelles fonctionnalités sont ajoutées à un monolithe, avoir de nombreux développeurs travaillant sur une base de code unique peut s'avérer laborieux. Les conflits de code se font plus fréquents, et le risque de mises à jour d'une fonctionnalité introduisant des bugs dans une fonctionnalité non liée augmente. L'apparition de ces schémas indésirables peut être le signe qu'il est temps d'envisager une migration vers les microservices.

Voici quelques-unes des bonnes pratiques apprises lors de notre migration :

Élaborer une stratégie de migration

Nous avons consacré beaucoup de temps à déterminer la séquence de migration des clients. Nous savions que beaucoup de nos clients auraient des profils et des dynamiques d'utilisation différents après leur migration. C'est pourquoi nous avons planifié en conséquence au préalable.

Penser aux outils

Les bons outils sont essentiels lors de la migration de microservices. Nous n'avons pas migré les clients immédiatement. Nous avons d'abord investi et créé des outils pour la migration, sachant qu'il s'agissait d'un marathon plutôt que d'un sprint. Le principal outil que nous avons créé était Microscope : notre propre catalogue de services interne pour suivre tous les microservices. Chaque développeur d'Atlassian peut utiliser Microscope pour consulter toutes les informations relatives aux microservices de l'entreprise.

Nous avons également intégré un outil dans Microscope appelé ServiceQuest. Il détecte automatiquement les vérifications de code avant la production, qui portent notamment sur la qualité, la conception des services, la confidentialité, la sécurité et la fiabilité.

En outre, un outil repose sur nos stacks techniques. Nous disposons d'un service interne qui nous permet de lancer un nouveau service sur une stack spécifique et qui précède des processus tels que la journalisation, la surveillance et la mise en cache. Enfin, nous avons automatisé autant que possible, y compris le processus de migration en lui-même. Nous avons créé notre propre tableau de bord pour visualiser efficacement toutes les migrations en temps réel.

Gérer les attentes

Une transformation d'entreprise nécessite un sponsor exécutif en chef, qui est tenu responsable des résultats et est prêt à rechercher les compromis nécessaires, déclare Sri Viswanath, CTO chez Atlassian. Cette personne devrait aider l'organisation à investir dans de nouveaux outils, systèmes et processus afin de rendre les améliorations permanentes.

Étant donné l'importance de la migration d'infrastructure et du nombre de personnes impliquées, l'entreprise souhaite connaître le retour sur investissement, déclare Mike Tria, Head of Platform chez Atlassian. Il est essentiel de maintenir la communication avec l'équipe de direction, les parties prenantes, les clients, les partenaires, et le reste des équipes de recherche et développement. Assurez-vous qu'ils savent ce que vous faites et connaissent les avantages attendus. De plus, n'oubliez pas de célébrer les victoires.

Amorcer un virage culturel

« La culture est essentielle dans ce genre de projets de grande envergure », déclare Sri Viswanath. « Vous voulez vous assurer qu'un ticket fait l'objet d'une remontée systématique. » Lorsque vous effectuez une migration, il ne s'agit pas simplement d'une migration technique, mais d'un changement de personnel et organisationnel. En 2015, Atlassian se contentait « d'écrire le code et de le livrer aveuglément » à l'équipe opérationnelle qui l'exécutait et le déployait. Fin 2017, nous avons adopté l'approche DevOps « Vous le concevez, vous en êtes responsable », chaque développeur Atlassian exécutant ses propres services.

« J'ai passé plus de temps à m'assurer que notre équipe SRE réussissait dans ce projet que pour la plupart des autres tâches que j'ai réalisées au cours du projet. En effet, le virage culturel induit par Vertigo a constitué la plus grande différence à long terme pour Atlassian », déclare Mike Tria.

Trouver l'équilibre entre vitesse et confiance

Nous aurions pu adopter Vertigo beaucoup plus rapidement. Au bout des quatre premiers mois, nous avons effectué 80 % des migrations. Nous aurions pu migrer les derniers utilisateurs, même si nous ne pouvions garantir qu'ils bénéficieraient de la fiabilité et des performances souhaitées. Nous nous sommes alignés sur l'une des valeurs fondamentales d'Atlassian : « Ne pas baratiner le client ».

Nous avons mis en place un système de contrôles avec nos ingénieurs afin de garantir une fiabilité élevée et nous avons respecté les normes strictes que nous nous étions fixées. Si votre conception est correcte dès le départ, vous gagnerez du temps et éviterez les maux de tête sur le long terme.

Lorsque nous avons examiné les 500 derniers clients, qui étaient les plus difficiles à migrer, nous avons utilisé l'intégration Jira Software et Trello pour assigner chaque client à un ingénieur Atlassian.

En résumé…


En janvier 2016, nous disposions d'environ 15 microservices. Aujourd'hui, nous en avons plus de 1 300. Nous avons migré 100 000 clients vers le cloud, créé une plateforme en cours de route, transformé notre culture et développé de nouveaux outils. Nos équipes sont plus satisfaites et autonomes, et nous avons amélioré notre culture DevOps.

Les microservices ne conviennent pas forcément à tout le monde. Un monolithe hérité peut parfaitement fonctionner, et il peut être utile de le décomposer. Mais à mesure que les organisations se développent et que les demandes relatives à leurs apps se multiplient, l'architecture de microservices peut s'avérer intéressante.

Étant donné que de nombreuses organisations ont tendance à opter pour des microservices dotés d'architectures distribuées, Atlassian a développé Compass pour aider les entreprises à gérer la complexité de ces architectures à mesure qu'elles évoluent. Il s'agit d'une plateforme de partage d'expériences extensible qui rassemble des informations déconnectées sur tous les résultats d'ingénierie et la collaboration des équipes dans un emplacement central et interrogeable.

Chandler Harris
Chandler Harris

Chandler Harris est stratège marketing et rédacteur pour Atlassian. Il a écrit plus de 40 publications différentes sur des sujets allant de la technologie, aux sciences, au monde de l'entreprise, à la finance et à l'enseignement.


Partager cet article

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Illustration DevOps

Communauté Compass

Illustration d'une équipe surmontant des obstacles

Tutoriel : Créer un composant

Illustration d'une carte

Lancez-vous gratuitement avec Compass

Inscrivez-vous à notre newsletter DevOps

Thank you for signing up