Architecture Microservices

Architecture

Introduction

Aujourd’hui, la majorité des géants du numérique (Google, Amazon, Facebook, Netflix, Uber, Paypal,…) ont adopté une architecture de type microservices pour leurs applications. Dans un monde en constante évolution technologique, cela leur a permis de tirer profit du Cloud et de faire face à la compétition avec les succès et les innovations qu’on leur connaît.  

On peut donc se demander dans quel contexte ce type d’architecture est-il profitable ? Mais surtout, quels sont les bienfaits et les problématiques induits par ce paradigme ?

Les monolithes

On oppose souvent l’architecture microservices à l’architecture dite monolithique. Une application monolithe est composée d’une seule unité applicative qui comprend généralement:

  • Une partie client (pages HTML et code javascript qui s’exécute dans le browser)
  • Une partie serveur (cœur de l’application, le monolithe)
  • Une base de données
Architecture monolithique

Eric Raymond a introduit la notion de « monolithe » dans son célèbre ouvrage « The Art of Unix Programming », voyons ses caractéristiques.

Avantages :

  • Bonne performance car tous les modules sont interconnectés au sein de l’application
  • Facilité de déploiement car on déploie une seule entité

Inconvénients :

  • Couplage fort entre les composants :
    • Si un composant est défaillant, c’est toute l’application qui ne répond plus.
    • La mise à jour d’un composant impacte fortement celles des autres.
  • Plus l’application grandit plus elle devient complexe à appréhender…surtout pour les nouveaux développeurs
  • Dès lors que l’on souhaite apporter une évolution, il faut re-tester et déployer l’intégralité de l’application
  • La parallélisation de nouvelles évolutions est compliquée, voire impossible…
  • Une seule stack technique pour toute l’application
  • Les effets de bord sont moins prévisibles

Comme on pouvait s’y attendre, ce type d’application n’est pas prévu pour absorber des changements fréquents, ce qui est un frein à l’innovation. De plus, une telle application est difficilement scalable pour répondre à des montées de charges, car il faudrait pour cela déployer plusieurs instances de cette même application. Une application monolithique n’est pas résiliente car le dysfonctionnement d’un composant entraine inévitablement son indisponibilité.

Les microservices

L’architecture microservices quant à elle, permet de répondre à ces problématiques avec une approche basée sur le principe « Divide and Rule ». L’architecture microservices consiste à découper une application en petits composants qui vont interagir entre eux, l’application devient donc distribuée.

Un microservice est :

  • Autonome
  • Indépendant
  • Stateless
  • Possède un périmètre fonctionnel précis
  • Possède sa propre base de données
  • « Fait une seule chose et la fait bien » (philosophie Unix)
  • Possède son propre langage

Un microservice doit être vu comme un produit en constante évolution qui répond à des besoins métier. Il est sous la responsabilité d’une seule équipe pendant toute sa durée de vie.

Petit flashback, à la fin des années 90, la SOA (Service Oriented Architecture) est conceptualisée. Sa mise en œuvre facilite l’intégration entre les applications avec une approche de services faiblement couplés et réutilisables. Ces services communiquent entre eux via un protocole commun (souvent SOAP) par l’intermédiaire d’un ESB (Entreprise Service Bus).

Hélas, un des gros points noirs de cette approche est l’ESB qui devient la colonne vertébrale de l’application. Il grossit à mesure que l’application évolue, il devient en quelque sorte le monolithe. Il suffit qu’il tombe en panne et toute l’application est hors-service. De plus, la SOA est plutôt utilisée au niveau du SI de l’entreprise pour faire communiquer des applications entre elles ou avec des services externes. Pour certains, l’approche microservices est une continuité de la SOA alors que d’autres y voient un changement complet. Ce qui est clair, c’est qu’on retrouve des concepts issus la SOA dans l’approche microservices.

En réalité, l’approche microservices va plus loin dans le sens où elle se définit au niveau d’une application qui est éclatée en petits composants fonctionnels. Les microservices vont communiquer entre eux via des protocoles légers (souvent via REST API ou par messages asynchrones).

Architecture microservices

Parmi les nombreux avantages d’une architecture microservices, on peut citer :

  • Les microservices sont indépendants les uns des autres : chaque composant possède son propre cycle de vie
  • L’application est plus résiliente : ce n’est pas parce que un service est KO que l’application entière est KO
  • Développement en parallèle de microservices
  • Découpage fonctionnel de l’application
  • Monitoring plus fin de l’application : ce qui permet d’identifier les microservices les plus sollicités
  • La maintenance est beaucoup plus facile : on fait évoluer uniquement les composants nécessaires
  • Les microservices peuvent utiliser des langages différents
  • Propice à l’innovation technologique dans le sens où on peut faire évoluer seulement un microservice dans un premier temps pour tester un langage ou un framework par exemple
  • La notion d’évolution progressive : différentes versions d’un microservice peuvent cohabiter
  • Application scalable : on déploie davantage d’instances pour les microservices plus utilisés

Une architecture aussi complexe entraîne de nouvelles problématiques telles que :

  • Latence due aux communication réseaux
  • Complexité de l’application déportée dans l’interaction entre les différents microservices
  • Nécessité de maintenir une cartographie des composants
  • Difficulté à packager l’application avec les microservices (chacun possédant sa propre version)
  • Difficulté à définir la granularité d’un microservice

Une application microservices est donc propice à absorber le changement rapidement, est scalable et plus tolérante aux pannes. Elle est parfaitement compatible avec une gestion de projets en mode Agile. En effet, elle facilite la gestion en parallèle de travaux menés par plusieurs équipes. Cela permet d’avoir des cycles de développement plus courts et donc un « time to market » plus court.

Cette approche s’accompagne également d’un changement d’état d’esprit, notamment par la mise en place de pratiques issues du DevOps. Cela peut être couteux au début, surtout s’il faut acquérir ces compétences au sein de l’équipe. Les développeurs peuvent ainsi se focaliser sur les fonctionnalités métiers de l’application grâce à l’automatisation des tâches récurrentes (passages de tests, couverture de code, détection de failles, déploiement,…).

Heureusement, l’architecture microservices a acquis une certaine maturité et une multitude d’outils permettent de faciliter sa mise en œuvre. En voici quelques exemples :

  • Container : Docker
  • Orchestrateur de container : Kubernetes
  • Package manager pour Kubernetes : Helm
  • Service Mesh : Istio, Traefik Mesh, Linkerd
  • Reverse-proxy : Traefik proxy, Istio ingress, NGINX
  • Outils de CI/CD : Gitlab CI/CD, Jenkins
  • Outils de monitoring : Kibana, Grafana, Zipkin, Jaeger
  • Système de cache distribué : Redis

L’architecture microservices et les containers ont permis l’émergence de ce que l’on appelle les applications « Cloud native ». En effet une telle architecture permet de tirer parti de l’élasticité du cloud pour ainsi répondre aux nouveaux besoins.

Conclusion

En résumé, l’architecture microservices permet de construire des applications qui s’adaptent très rapidement :

  • Au changement : les évolutions sont plus fréquentes et moins impactantes
  • A la charge : les instances de microservices peuvent être déployées en fonction de la demande
  • A la panne : l’application continue de fonctionner si un microservice n’est plus opérationnel

Références

Publié le 03/01/22

 


Partagez cet article :