Introduction

Tandis que la technologie évolue sans cesse, les développeurs se retrouvent de plus en plus confrontés à un choix face à la diversité des techniques de développement logiciel. 

Dans cet article, nous allons nous attacher à expliciter pour quelles raisons et pour quels projets se diriger – ou non – vers les microservicesou rester sur les applications monolithes que l’on considère comme plus simple d’utilisation.  

Définitions

L’architecture des microservices relate d’une méthodologie de développement logiciel en plein essor. Si aucune définition n’a été définie comme “officielle”, il existe un modèle, un pattern de caractéristiques techniques qui permettent d’établir le profil de l’architecture microservices. Ainsi, cette dernière se décrirait comme étant un ensemble de services indépendants mais modulables. A l’intérieur de cet ensemble, ce sont chacun des services qui exécutent individuellement un processus définit et unique à chacun. L’agglomération de ces microservices sert à atteindre un but spécifique pour l’entreprise. 

A l’opposé de ce système, on retrouve la notion de style monolithique. Bien plus ancien et aujourd’hui moins ‘tendance’ auprès des développeurs, il se diffère des microservices par son unité complète et autonome ; c’est-à-dire que l’ensemble de processus fait corps et n’est pas divisé ni divisible en plusieurs services. Partant du plus classique des modèles : client à serveur, ce dernier sert notamment à gérer les différentes requêtes http et à mettre à jour la base de données.   

L’architecture orientée service (SOA), le précurseur aux microservices ?

Avant que le débat entre architecture monolithique et microservices ne fasse rage, il est important de rappeler que le concept de séparation d’une application en divers services date déjà d’il y a quelques temps avec l’architecture dite SOA (Service Oriented Architecture), véritable modèle d’interaction applicative mettant en corrélation plusieurs services.  

LE SOA offre un processus d’échange de messages sécurisés entre les différents systèmes d’informations intégrés, le tout en usant de protocoles de communication dits standardisés. Cette approche offre à l’architecture une opportunité d’ouverture sur un large éventail de solution logicielle existante. La motivation fondamentale vient du constat suivant : les blocs monolithiques sont une source majeure des difficultés rencontrées pour le traitement des évolutions et de la maintenance des systèmes (d’où la future introduction des microservices).  

Schéma Architecture Orientée Service

Le SOA introduit les notions de fournisseur, de consommateur de service et de registre de service, que l’on peut déterminer comme suit :  

  • Le fournisseur de service est l’acteur responsable du développement du service, de son déploiement, de son exécution  
  • Le consommateur de service est l’acteur qui utilise les services en fonction de ses besoins  
  • Le registre de services (service broker) est l’acteur qui enregistre les informations et permet de faire le lien entre consommateur et fournisseur, les fournisseurs publient les services dans ces registres qui sont ensuite consultées par les consommateurs 

Les avantages du SOA sont globalement les mêmes que les microservices, à savoir la modularité, la nécessité d’acquérir une modélisation poussée, la possibilité de découpler les accès aux traitements avec la facilité d’ajout et de mise à jour de service, la localisation et l’interfaçage transparent des services, la scalabilité et le tout dans un objectif de réduction des coûts de maintenance et d’évolution. 

En revanche, s’il est aujourd’hui logique de voir une transformation des usages vers les microservices, cela peut s’entendre par les nombreux inconvénients que possède le SOA, avec entre autres : 

  • Les coûts de conception et de développement initiaux  
  • La nécessité d’appréhender de nouvelles technologies (peut aussi être un atout dans la montée en compétence quotidienne) 
  • L’existant n’étant pas qualifié SOA dans les entreprises est donc plus difficile à gérer en parallèle 
  • Les performances réduites pour des traitements pourtant relativement simples 

SOA & Microservices, un même combat ? Pas vraiment !

S’ils ont de nombreux points communs, le SOA et les microservices n’en sont pas moins deux entités procédurales bien distinctes. Le fait qu’ils aient tous les deux pour but de séparer des modules grâce à des services. 

Les microservices sont distinctifs du SOA à plusieurs échelles, on peut d’ores et déjà citer la définition des services et des méthodes et leurs créations ainsi que leurs étendues et leurs principes. Si l’on se base sur l’exemple de Amazon pour les microservices, on voit que la nuance est fine puisque la société déclare travailler en SOA. Quand bien même les différences sont faibles, elles existent. S’il est possible de dire que travailler en architecture de microservices revient à faire du SOA de manière un peu particulière, l’inverse est moins vrai. D’ailleurs, Les services d’une architecture spécifique en SOA sont, ou du moins peuvent être, responsable d’une ou diverses fonctionnalités. Ils peuvent aussi atteindre une taille/poids énorme tandis que les microservices se doivent d’être plus petits et se focaliser sur une unique fonctionnalité.  

Autre différence notable, les architectures microservices sont le fait de plusieurs grands acteurs du web 3.0 comme Netflix, Amazon ou encore Airbnb, qui cherchent principalement à répondre directement à leurs exigences économiques et/ou organisationnelles. Le SOA est lui bien plus axé sous les ESB (Entreprise Service Bus) et EAI (Enterprise Application Integration) classiques.  

En sommes, la principale et majeure différenciation à faire entre ces deux architectures est le fait que le SOA est une notion qui s’applique généralement plutôt à une entreprise tandis que les microservices ont, eux, tendance à ne voir le jour que dans une (ou plusieurs) équipes au sein d’une même entreprise. La raison est simple pour ces derniers, le fait qu’ils ne répondent qu’à l’architecture d’une seule et même application, même si cette dernière pèse son poids en code. Identiques en bien des points, la divergence est donc réelle et se retrouve tant dans la conception, les détails techniques que l’application finale. 

Quelle évolution ?

Au départ, l’architecture monolithique suffisait amplement et était aussi valorisée par sa simplicité. Dorénavant, les microservices prennent le pas sur l’autre modèle pour diverses raisons. La première d’entre elle est le fait que l’architecture monolithique empêche la modification individuelle des parties puisque l’ensemble des cycles évolutif sont liés entre eux et l’apport d’une modification à l’un de ces cycles impute la modification des autres. En sommes, si vous souhaitez modifier une fonctionnalité de l’application en particulier, vous devrez certainement modifier l’ensemble de la version et en proposer une nouvelle, complète. Pour contrer ce problème récurrent sont apparus les microservices. En divisant chacun des cycles, il devient bien plus aisé d’apporter une maintenabilité et une compatibilité entre les différents OS ou plateformes utilisées.   

⚠️
le fait que l’architecture monolithique soit une et indivisible ne veut pas dire qu’elle est simple pour autant.

En revanche, il est commun d’avouer que l’architecture en microservices est plus complexe à mettre en place puisque bien plus complète et avec de nombreux nouveaux facteurs techniques à prendre en compte.

Avantages et inconvénients des architectures

Bien que subjectif, on peut avancer le fait que l’architecture monolithique perd du terrain face à sa rivale. Le premier avantage des microservices est sa fiabilité induite par le fait que, même en cas de rupture d’un de ces services, l’entièreté du projet n’est pas remise en cause.  

Prenons un exemple : si vous avez décidé de créer une application pour une grande chaîne de fast-food mais qu’un menu en particulier ne s’affiche plus sur les bornes, cela n’influe pas sur le reste des menus ni même sur la commande envoyée en cuisine. Les problèmes sont donc, généralement, moins impactant sur l’ensemble de la structure qu’avec une architecture monolithique.  

Cet avantage non négligeable est pourtant à nuancer puisqu’il implique un travail bien plus ardu lors du déploiement de chaque microservice. En effet, il ne faut surtout pas omettre d’unifier les formats des pipelines ou encore définir au préalable les outils nécessaires au fonctionnement des services. C’est là que l’architecture monolithique tire un léger avantage puisque ces applications permettent un déploiement unique et surtout des modifications au gré de la demande.  

Pour la maintenance, c’est une nouvelle fois à l’avantage de l’architecture monolithique puisque son modèle ne réclame qu’une surveillance globale tandis que les microservices implique une familiarité avec les différents outils usités : Dockerou Kubernetespour ne citer qu’eux. C’est un travail quotidien que de vérifier que l’intégration et le déploiement continue de CHAQUE microservice et de l’infrastructure ENTIERE fonctionne. C’est donc une nouvelle fois un travail préalable à faire que de choisir les bons outils pour faciliter la tâche du développeur. On ne peut que prescrire l’utilisation du DevOpspour faciliter l’ensemble de cette tâche.  

Une fois n’est pas coutume, les microservices remportent la palme du vainqueur lorsqu’il s’agit de scalabilité grâce au fait que leurs ressources sont plus faciles à gérer du fait qu’elles soient multiples. Il est alors bien plus facile de s’attarder sur celles qui posent des problèmes et de laisser de côté les services déjà à jour. Il est évident qu’avec un projet unique sous architecture monolithique, il devient plus compliqué d’utiliser les ressources sur les services impactés puisque ces derniers sont agglomérés de fait à ne former qu’un. Il y a plus dangereux pour votre projet, vous risquez d’écrire votre code d’une manière qui le rendrait impossible à mettre à l’échelle horizontale, ne laissant que la mise à l’échelle verticale possible pour votre application monolithique.

 Il est d’ailleurs à noter que l’hétérogénéité technologique est l’élément fort qui permet cette scalabilité et cette maintenabilité chez les microservices. Puisque, du fait que chaque microservice n’a pas besoin de connaître la technologie utilisée par les autres, il est donc possible d’avoir des services différents n’utilisant alors pas les mêmes technologies. Ainsi, il est aisé d’adapter les technologies selon les problèmes rencontrés. Attention cependant, l’agglomération de trop de technologies risque de rendre la documentation et la communication complexes et, de fil en aiguille, imputer sur la mobilité des développeurs entre les différents services. 

Au niveau de la libération, c’est finalement les microservices qui remportent le trophée de champion. Si ces derniers sont associés à une architecture de communication appropriée, alors il devient possible de lancer de nouvelles fonctionnalités plus rapidement en réduisant le temps donné à l’assurance qualité, le temps de construction et le temps d’exécution des tests. Contrairement aux microservices, les applications monolithiques ont beaucoup de dépendances internes qui ne peuvent être brisées. Elle comporte d’ailleurs un risque plus élevé selon que votre engagement dépende de changements inachevés de la part des membres de votre équipe. A terme, cela peut retarder la livraison de la nouvelle version. Chaque service contenant au moins un processus, l’interruption d’un service n’empêchera pas d’autres services de continuer à fonctionner. L’application n’est plus soit en marche, soit interrompue, mais peut être dans des états intermédiaires. Cela permet donc de réduire le temps ou l’application est inutilisable dans son ensemble, et le remplace par un moment ou l’application ne fonctionne que partiellement, pouvant dans la plupart des cas répondre au besoin du client. 

Mais, la véritable question qui se pose est : peut-on vraiment pratiquer l’un sans l’autre ? Eléments de réponse dans la prochaine partie. 

De l’architecture monolithique aux microservices, comment, pourquoi, une transition obligatoire ?

La transformation architecturale, le moyen le plus qualitatif

Prenons un cas concret et que tout à chacun peut voir au quotidien : Netflix. Parmi la multitude de compagnies ayant transformé leur application monolithique vers des architectures microservices, elle et sa rivale Amazone ont su tirer leur épingle du jeu dans cette transition qui peut s’avérer parfois complexe, même si cette même transition est parfois considérée comme l’unique bonne manière d’intégrer les microservices à l’application (mieux donc que de créer l’application directement en microservices).  

La recette est relativement simple : 

  • Prenez une application préexistante et de bonne taille 
  • Découpez-la progressivement en différents services 
  • N’hésitez pas à y ajouter de nouvelles fonctionnalités. Au besoin, développer de nouveaux services pour les intégrer. 

L’avantage ? Pour tirer bénéfice des microservices, rien ne sert donc d’attendre qu’une application soit trop volumineuse ; préférez donc une migration du monolithique aux microservices si possible. D’autant que cela est quasiment l’unique solution de qualité lorsque le volume de code de votre application est si imposant qu’il devient compliqué de le maintenir et de conserver un déploiement rapide. 

L’avantage ultime d’une transition “en douceur” est de permettre à l’ensemble des équipes liées par le projet de construire une bonne communication, ainsi qu’une bonne documentation, afin que chacun sache comment et pourquoi le projet évolue. La question du pourquoi est-elle aussi primordiale étant donné que la première chose à faire lors d’une transformation architecturale est de se demander pourquoi l’architecte précédent avait choisi telle ou telle architecture. Si, à termes, l’application ne répond plus aux besoins des utilisateurs, la transformation n’aura servi à rien. 

“Prudence est mère de sûreté.”  

2 – Débuter directement en microservices, une fausse bonne idée ?

Les microservices peuvent aussi être utilisés dans une nouvelle application sans forcément demander une transition depuis une ancienne architecture monolithique. Afin d’utiliser les microservices en tant que pierres fondatrices de la nouvelle architecture, l’architecte doit impérativement être au fait de toutes les caractéristiques du métier client afin de réaliser un découpage de services au plus proche des fonctionnalités demandées par le PO. Hormis le facteur temps qui va rapidement être élevé, il est difficile de présenter rapidement un premier rendu au client. Le coût développement/temps est à prendre en compte.  

Personnellement, nous vous conseillerons de préférer une migration depuis une application monolithique vers une application en microservices. 

3 – Réfléchir à un plan d’évolution dès la création du projet

Il est tout à fait envisageable de commencer un projet via une architecture monolithique, le tout en sachant pertinemment qu’une transition vers les microservices va rapidement voir le jour. Ainsi, cela vous permet de vous créer un plan d’évolution à même de vous apporter les avantages des deux architectures : temps, déploiement rapide, bonne documentation, bonne communication des équipes, rentabilité exacerbée.  

En effet, cette approche permet avant tout de réduire le temps de développement – et donc de recevoir le feedback utilisateur rapidement – tout en bénéficiant des avantages non négligeables des microservices : hétérogénéité technologique, scalabilité, résilience, testabilité. Par ailleurs, commencer en monolithique permettra aussi, le cas échéant, de vous arrêter dans votre transition si – finalement – les microservices ne vous apparaissent plus comme nécessaires. Évidemment, faire marche arrière aura un coût, tout comme le fait d’utiliser les deux architectures. Ce coût doit être réfléchi à la minute même où vous abordez le sujet de l’architecture en amont du projet. Plus l’application sera conséquente, plus ce coût de transformation sera élevé, tant en temps que d’un point de vue économique. Il est donc nécessaire de trouver le juste milieu si on veut utiliser cette méthode. 

À chaque projet son architecture

Avant de vous lancer à corps perdu dans votre projet, il est nécessaire et obligatoire de penser à jauger les pours et les contres de chaque architecture. Aussi, voici un léger récapitulatif des différents critères d’adaptabilité à un projet selon l’architecture.  

Si votre équipe est réduite ou ne possède que peu d’expérience sur les frameworks solides (Ruby on Rails par exemple) et que vous souhaitez/devez sortir un produit minimum viable (MVP) – donc rapide -, privilégiez une architecture monolithique.  

En revanche, si vous n’avez pas d’échéancier à deadline courte, que votre équipe est qualifiée sur plusieurs frameworks et/ou langages et que l’évolutivité et la maintenabilité de votre produit est à vos yeux le plus important, on ne peut que vous conseiller de vous diriger vers l’architecture de microservices.  

Les alternatives d’avenir

Si la liste des avantages est non négligeable pour les microservices, nous sommes en droit de nous poser la question de savoir quelles pourront être les prochains types d’architectures à même de proposer de tels services.  

⚠️ Rappelons-le, le choix de l’architecture doit être fait, non par préférence, mais de son intérêt vis-à-vis de votre projet (taille, équipes, humain, service client) !

Si la liste des avantages est non négligeable pour les microservices, nous sommes en droit de nous poser la question de savoir quelles pourront être les prochains types d’architectures à même de proposer de tels services.