Une architecture en micro service (également appelé micro application ou encore small app) est une façon de concevoir les applications. Le principe est de créer un ensemble de petites applications (ou services) autonomes qui communiquent entre elles par un protocole simple (ex par API Rest). Elles sont conçues pour répondre à une fonction business spécifique et doivent pouvoir être déployées facilement et indépendamment. Chaque microservice peut être écrit dans un langage de programmation différent ou utiliser des bases de données spécifiques.

Les retours d’expérience sur ce type d’architecture sont positifs et de plus en plus utilisés, au point où cela devient un standard pour les gros applicatifs.

Comparaison avec une architecture monolithique

Habituellement, les applications sont en 3 parties différentes: l’interface utilisateur (développée en HTML / javascript), une base de données (habituellement une base SQL) et une application côté serveur (développé en PHP, Java, Ruby, …). L’application côté serveur est responsable du stockage de la données et de la génération de l’HTML pour le front. Cela présente les inconvénients suivants:

  • toute la logique de l’application se retrouve donc dans une seule application, écrite dans un seul langage de programmation. On n’exploite pas les capacités des différents (ex: R pour les statistiques)
  • les modifications sur l’application peuvent impacter d’autres modules
  • pour assurer la montée en charge, il faut une montée à l’échelle horizontale en déployant l’application au complet sur plusieurs serveurs
  • à chaque modification apportée à l’application, le cycle de développement est long (définition du fonctionnel, développement, tests, déploiement)
  • au fil du temps, il est de plus en plus difficile de garder l’architecture modulaire prévue à l’origine
  • chaque développeur doit avoir l’application au complet dans son environnement de développement et doit comprendre la majeure partie de l’application

Ces inconvénients ont conduit à penser les modules comme des services et l’application comme une suite de services. Chaque service est indépendant, avec une montée à l’échelle indépendamment, écrit dans différents langages et par des équipes différentes. La complexité de l’application est cassée en un ensemble de modules facile à maintenir. Certains architectes expliquent que le problème résolu par un service doit pouvoir être mentalement représenté.

Idéal pour les évolutions fréquentes

De plus en plus d’applicatifs et de sites web doivent évoluer constamment. L’architecture en microservice répond à l’enjeu qui repose sur l’équipe informatique qui doit pouvoir apporter des modifications sans ralentir les temps de développement. L’architecture se prête même très bienà la création des services « brouillons », idéal pour le lean startup.

Architecture idéale pour la tolérance aux pannes

Lorsqu’on développe une application en microservice, cela oblige à prévoir dans l’application qu’un service puisse être défaillant. D’abord, l’application peut continuer à fonctionner dans un mode dégradé. Ensuite, les services étant plus simples, il est plus facile de les restaurer. Une brique importante dans cette architecture est le monitoring en temps réel des services. Le monitoring doit fournir les bonnes mesures pour surveiller les échanges entre services.

L’avenir de l’architecture en microservices

Cette architecture est de plus en plus utilisée et a déjà mise en place avec succés pour de nombreuses applications et sites web. Cependant, ce design est encore récent et la durée de vie des applications n’ont pas encore atteind celle de certaines applications monolithiques.


Voir un exemple d’architecture en microservice pour un job board


 

Des questions, des remarques ou vous voulez tout simplement échanger? Appelez nous au 04 73 44 56 40

Tagged on: