Pourquoi passer aux architectures microservices ?

Le processus de modernisation commence par se poser les bonnes questions

Vue aérienne d'un garage à conteneur

Les microservices, une mode ?

Les microservices sont sur le devant de la scène. Promus par les témoignages de Netflix, Amazon et d'autres, ils apparaissent désormais comme une solution pour les grosses applications évolutives.

L'idée n'est pas neuve, elle a pris une première tournure sérieuse avec les architectures orientées services SOA, et s'est poursuivie avec ce concept de microservices complets autonomes.

Vue aérienne d'un garage à conteneur

Les microservices, une mode ?

Les microservices sont sur le devant de la scène. Promus par les témoignages de Netflix, Amazon et d'autres, ils apparaissent désormais comme une solution pour les grosses applications évolutives.

L'idée n'est pas neuve, elle a pris une première tournure sérieuse avec les architectures orientées services SOA, et s'est poursuivie avec ce concept de microservices complets autonomes.

Cette vision plus verticale et parallèle que le principe horizontal des couches repose sur deux principes philosophiques : les organismes spécialisés sont performants, les petits indépendants et complémentaires se révèlent souvent plus résilients que l’unique, multiusage mais boursoufflé. Les dinosaures ont disparu, mais pas les bactéries.

La réduction de la complexité au service de la rapidité

Transposée à l'informatique, cette idée revient à spécialiser des composants pour fournir des services définis, délimités et précis, à les rendre indépendants, autonomes. Rapportée à une application complète, il s’agit de la subdiviser en ensembles rendant chacun une partie la plus autonome possible du service à l’utilisateur.

En limitant complexité et couplages, cette architecture améliore sa robustesse, sa flexibilité et sa maintenabilité. En effet, une application construite à partir de microservices pourra évoluer par partie, utiliser des technologies distinctes. Chaque microservice, de taille plus modeste et à l’objectif bien défini, sera plus facilement maîtrisé que l'application globale, dite monolithique.

À faire une chose à la fois, on le fait bien. Qui comprend encore vraiment l'ensemble d'une grosse application monolithique, ses interactions internes et sa multitude de couplages ? La faire vivre devient progressivement cauchemardesque.

La migration n'est pas simple et un processus bien rôdé est nécessaire

L'idée est séduisante, et la technologie permet enfin une mise en œuvre efficiente des microservices. La découpe du monolithique en parties indépendantes n'est pourtant pas si aisée, et les tentatives de créer ex nihilo une application microservice sont généralement des échecs, au moins relatifs.

La pratique de l'exploitation opérationnelle d'une application permet d'en bien identifier les compartiments suffisamment isolables. Par nature, le besoin en gestion de configuration s'avère vite plus lourd. Il y a une inévitable duplication de travaux liée au nombre de microservices qui sont autant d'applications au sens informatique.

Le compromis se dégage à partir d'une taille où les gains en maintenance évolutive et corrective l'emportent sur le coût des duplications.

Quels sont les critères objectifs qui favorisent la modernisation d'une application

clavier d'une machine à écrire

L'application est *legacy*

Elle s’est généralement erratiquement complexifiée, victime de son histoire opérationnelle. Elle présente tous les risques de boursouflure, mais aussi d’obsolescence.

En contrepartie, l'analyse des couplages existants est plus facile, son utilisation effective mieux cernée. Les chaînes fonctionnelles autonomes peuvent être identifiées puis isolées comme services dans des conteneurs, les données internes rassemblées, les API pour les données communes bien définis.