Microservices et 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.

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.

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.

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.

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.

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.

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 :

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.