SOA (Service Oriented Architecture) et microservices sont deux façons différentes d’envisager l’architecture technique d’un projet. Dans le déploiement d’un projet technique, la question de son architecture se pose dès le début. Si certains responsables informatiques ont des préférences systématiques vers l’une ou l’autre de ces architectures, il est plus rationnel d’envisager le projet dans sa globalité pour faire le bon choix.
Et la réponse est difficile à mettre en place puisque il faut anticiper la « scalabilité » dudit projet, son évolution à court, moyen et long terme. La question n’en reste pas moins cruciale : architecture monolithique, SOA ou microservices ? Découvrez les points communs et les différences entre deux systèmes afin de prendre la meilleure décision.
SOA, microservices : deux styles d’architecture
L’architecture SOA
La SOA est apparue pour régler des problèmes d’interopérabilités ; lorsqu’il s’agit par exemple de faire communiquer deux applications fonctionnant sur des technologies différentes (java et .Net, Windows et Linux, etc…).
Dans une SOA, toutes les applications doivent se connecter à un ESB (Entreprise Service Bus) afin de communiquer avec les autres applications. L’ESB agit comme la colonne vertébrale de l’intégration, à travers laquelle les services logiciels et les composants applicatifs circulent. L’ESB permet de transformer les données, de les compléter et de les enrichir.
L’architecture microservice MS : fini le « plat de spaghetti »
L’architecture microservice est apparue pour régler des problèmes d’évolutivité du « plat de spaghetti ». C’est l’expression qui désigne un ensemble de services fortement couplés. Si bien couplés qu’il en devient difficile de modifier un service sans en impacter un autre.
Une application microservice est un ensemble de microservices faiblement couplés. Chaque microservice peut être modifié et livré de façon indépendante, sans impacter les autres services. On peut dire en cela que l’architecture microservice est une évolution du SOA. Elle propose une granularité plus fine pour répondre à de nouveaux besoins, comme baisser le « time to market » en ne livrant et ne testant que le strict nécessaire.
Un microservice est :
- élastique : scalable indépendamment des autres microservices.
- résilient : si ce service crash, il ne doit pas impacter les autres microservices.
- composable : il doit offrir une interface favorisant son utilisation
- minimal : le service ne doit faire qu’une seule chose (on parle de forte cohésion)
- complet : le service doit fonctionner seul.
On dit souvent qu’un microservice doit être minimal mais complet.
Les contraintes d’une architecture microservice
L’architecture microservice engendre de nouvelles contraintes et difficultés, pour permettre ce faible couplage des microservices.
Le meilleur exemple est la gestion de la base de données. Comme chaque microservice possède sa propre base de données, il faut donc prévoir une communication entre microservices pour mettre à jour ses bases et conserver la cohérence des données (via un système de messagerie tel que ActiveMQ ou Kafka). Alors que dans la SOA, une application regroupant plusieurs services ne possède qu’une seule base de données.
Pourquoi mettre en place une architecture microservice ?
Une application monolithique a tendance à mal vieillir : chaque nouvel ajout de fonctionnalité ou correction de bugs peut entraîner des régressions. Cela vient du fait que certains bouts de codes ou certaines méthodes sont réutilisés par différents services.
L’application monolithique est aussi plus difficile à tester car elle nécessite plus de prérequis (LDAP, base de données, mail …) qu’un simple microservice.
L’architecture microservice permet de gérer chaque service de façon indépendante : son évolution, sa livraison et ses performances.
Avec quelles technologies fonctionnent les architectures microservice ?
Il faut faire attention à ne pas négliger la courbe d’apprentissage des différents concepts et outils nécessaires à l’application d’une architecture microservice.
On trouve par exemple :
- le Framework Spring Boot: il facilite la création d’applications autonomes (ne nécessitant pas de serveur d’application tel que JBOSS)
- Apache Kafka: système de messagerie permettant la communication entre microservices
- API gateway : permet la gestion (sécurité, logs) et la centralisation des microservices
- Logstash / Kibana: permet la centralisation des logs des microservices
- Docker: permet de charger ses microservices sur des containers pour les tester
- Devops : permet de développer, tester, déployer rapidement ses microservices
- Kubernetes: permet d’automatiser la gestion de ses containers dockers.
La transition du SOA aux microservices peut donc être un exercice difficile. Cela implique d’apprendre à utiliser de nouveaux concepts : Kafka, Docker, devops, intégration continue, tests unitaires et intégrations etc. La transformation touche aux outils, via des modèles plus modernes et flexibles, et à la « culture » de la gestion de projet. Quant à la migration d’une application monolithique en plusieurs applications microservices, c’est encore plus difficile : Il faut découper toutes les fonctionnalités en services indépendants, repenser toute la base de données, ajouter les interactions entre microservices via messages.
Chez Blue Soft, nous pouvons éclairer cette démarche et vous apporter notre savoir-faire en matière de microservices. Faites-vous accompagner par nos Experts Digital pour discuter de votre projet !
