Micro services … mais pourquoi ?

Micro services … mais pourquoi ?

Les micro-services arrivent à grands pas dans nos architectures et viennent percuter nos organisations et notre mode de travail. Mais au fait, d’où viennent-ils et pourquoi ont-ils autant de succès ?

Les micro-services arrivent à grands pas dans nos architectures et viennent percuter jusqu’à nos organisations et notre mode de travail.

Mais au fait, d’où viennent-ils et pourquoi ont-ils autant de succès ?

Evolution des architectures

Voilà quelques années, voir maintenant quelques décennies, le web est apparu. 

Au travers de l’évolution des besoins et des pratiques, ses technologies et ses architectures se sont adaptées et ont évoluées.

En voici quelques étapes clés.

Etapes clés micro services

Au début était les CGI

Les premières applications utilisaient des architectures simples et essentiellement basées sur un client web réduit à son plus simple appareil et un serveur utilisant le plus souvent des CGI. 

Des serveurs en couches 

Les applications grossissant et s’intégrant plus largement dans les SI, les architectures serveurs ont évoluée pour organiser les applications en couche sous l’impulsion de technologies comme le J2EE. Le tout ayant pour objectif de faciliter les développements et la maintenance. Cette approche fonctionne si l’on prend une vue verticale par application mais atteint ces limites pour les très grosses applications rendant toujours extrêmement difficile les montées de version applicatives ou technologiques

Séparation des services et de la présentation 

Est ensuite arrivée l’idée d’architecture de service (souvent appelé SOA). Les services ont été sortis pour les rendre, souvent sans succès, réutilisables au travers de l’entreprise et plus facilement maintenables. Le fait est que peu de d’implémentation de SOA ont démontré un ROI à ce jour en termes de facilité de maintenance, de TOC, d’agilité et de qualité avec souvent un manque de gouvernance associé et une dépendance trop forte des services avec leur écho système.

L’arrivée du « client riche »

Un des changements majeurs qui a percuté nos architectures est l’arrivée du « client riche » HTML5/JS et des applications mobiles. Cela nous a forcé à reconsidérer notre approche en termes d’architecture.  
Avec l’apparition des Single Page Applications (SPA) HTML5/JS et des applications mobiles, le paradigme MVC/MV* s’est logiquement déplacé du serveur vers le client. En outre cela a aussi permis la gestion du mode déconnecté d’une application, très important en situation de mobilité.

Dans cette évolution, le serveur héberge seulement les services (le plus souvent REST/JSON) consommés par les SPA ou les applications mobiles.

Il n’en reste pas moins que le plus souvent ces services servent principalement une « application », ou un ensemble de canaux d’une application, mais restent intimement liés en termes de logique métier, de cycle de vie logiciel.

Design API ou *AAS (Everythinq As A Service)

Le cloud et le développement de plus en plus fréquent de solutions multi-clients (Mobile App, Web, Service à service…) ainsi que le besoin d’ouverture des SI vers des partenaires, nous amène à changer notre façon de penser l’architecture et de passer du paradigme Service à celui d’API.
Une API est le regroupement d’un contrat d’interface (celle du service), des SLA associés et d’une gestion des accès. 

La brique centrale d’une architecture basée sur les API est l’outil API Management, qui prend en charge les SLA et la gestion d’accès, permettant même une facturation à l’utilisation.
D’un point de vue organisation, il est nécessaire d’envisager chaque API comme une application, avec son propre cycle de vie, son propre environnement d’exécution (avec son monitoring), sa propre logique métier et ses propres données, sa propre équipe avec son Product Manager (responsable de la roadmap du service), son équipe IT et ITO, son expert métier, etc. 

Micro Service

On parle de Micro Services, quand chaque API est construite autour d’un unique besoin fonctionnel (Gestion des utilisateurs, …)


Ce type de solutions lèvent les contraintes techniques qui freinent l’Agilité et améliorent nettement le time-to-market.

Solution

Avantages et Inconvénients

  • Les atouts majeurs sont :
  • La réduction de la complexité (1 service = 1 besoin)
  • Permet une scalabilté horizontale
  • Décentralisation 
  • Un meilleur contrôle des impacts des changements ou évolutions
  • Testabilité simplifiée 
  • Réduit les délais de mise en œuvre
  • Permet l’utilisation de la meilleure technologie (« the right tool for the right purpose »)
  • Facilite l’innovation technologique 
  • Intégration de composants externes simplifiés
  • Renforce la nécessité du test de bout en bout (E2E tests)    

Comme toute solution apporte aussi son lot de contraintes il est important de noter les points d’attentions suivant :

  • Changement majeur du mindset pour les équipes 
  • Impact sur l’organisation des données, (Quid des transactions, des jointures, …)
  • Changement d’organisation des équipes et de la gouvernance projet
  • Granularité des services 
  • Synchronisation des données multi services 
  • Sécurité des services
  • Gestion des dépendances et de la configuration (service discovery et service registry)


En conclusion

Les besoins de transformation des DSI autour de l’agilité, d’un meilleurs time-to-market, et d’une ouverture vers l’extérieur milite pour la mise en œuvre d’architectures de type micro-services d’autant que les solutions technologiques facilitent largement leurs mises en œuvre.

François Cherpion

Partager

Vous aimerez aussi

+
+
+