Pourquoi passer aux architectures microservices ?

Le processus de modernisation commence par se poser les bonnes questions

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

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.

L'application doit être régulièrement mise à jour et fait l'objet d'évolutions

Un contexte d'évolutions et de mises à jour fréquentes militera pour une subdivision en microservices. Cela pourra être l'occasion de porter certaines parties dans des environnements de développement plus adaptés, l’unicité n’étant plus une contrainte avec des API bien choisis, comme REST.

La disponibilité globale de l'appli sera par la suite augmentée puisque modifiable par partie. On parle de livraison continue et d'agilité.

Chaque évolution devient de plus en plus complexe à réaliser

Les applications monolithiques présentent souvent cette difficulté exponentielle : elle ne s'arrangera pas avec le temps, bien au contraire. Les microservices seront mieux maîtrisables par leur taille réduite, les ressources humaines mieux affectées.

En théorie, après un bon travail de découplage, les évolutions n’impactent souvent qu’un microservice.

Des problématiques de performances sont récurrentes

Ce point est aussi souvent généré par la taille, la complexité et les couplages internes. De plus, il y a création de maillons faibles qui pénalisent l'ensemble.

La compartimentation offre deux avantages : le retour à des tailles intrinsèquement plus optimisables, et le découplage qui permet de préserver indépendamment les performances de chaque fonction rendue.

Les coûts d'infrastructure serveurs sont en augmentation

Un signe d’une application boursoufflée est le besoin croissant en infrastructure : le matériel n’est plus calibré. Il y a compensation matérielle pour tenir les performances.

Sous forme de microservices autonomes, la répartition sur des serveurs indépendants, chacun mieux dimensionné, est un atout maître de cette architecture microservice. Elle s'adapte bien au Cloud d'ailleurs.

La société dispose d'une petite équipe de développement

L'avantage en matière d'organisation est généralement l'optimisation dédiée par microservice (fonctionnellement spécialisé) et par besoin transverse (techniquement spécialisé).

Les petites structures sont beaucoup plus sensibles aux effets de seuil engendrés par la difficulté du maintien en condition des grosses applications. Le passage aux microservices permet de redéployer une petite équipe sans subir l'inflation de besoins. Une grosse entité aura plus longtemps le choix.

En conclusion...

Pour résumer, les situations qui seront améliorées par une architecture microservices sont assez courantes et nombreuses. Elles s’entendent souvent dans une logique d’exploitation rendue difficile au fil du temps. C’est dans ce cas une très bonne option pérenne.

Netsach propose des services et des solutions permettant d'accélérer concrètement la modernisation et la transformation des applications métiers.