SOA versus Microservices : quelles différences ?

Les DSI ayant monté une Architecture Orientée Services (SOA) sont nombreuses à hésiter à franchir le pas vers les Microservices. Quelles sont les différences entre ces deux types d’Architectures ? Quels sont les prérequis des Microservices en termes de méthode et d’outillage ? Et, surtout, comment migrer de l’un à l’autre ? Réponses.

Les Microservices : une autre philosophie ?

Commençons déjà par un constat clair, émis par les précurseurs des Microservices : cette Architecture est une extension du concept de SOA. La plupart des principes de conception des Microservices étaient déjà disponibles dans le monde de la SOA. Alors, où est la nouveauté ? D’un point de vue conception, la nouveauté réside principalement dans la description fine des designs patterns à utiliser. La SOA nous offrait une boîte à outils vaste et d’excellents principes d’Architecture : les Microservices nous apportent une série de bonnes pratiques et de patrons de conception plus réduits et plus adaptés aux contraintes du moment (déploiement quotidien, time to market réduit à quelques jours, interconnexion entre les applications internes et externes, relation client multi-canal). Disons simplement qu’il s’agit d’un best of de ce que propose la SOA.

Du SOA aux Microservices : nouveaux principes ?

Une Architecture Microservices repose sur un certain nombre de principes supposés nous garantir les points essentiels :

• Non-adhérence entre les applications (une mise à jour corrective ou évolutive d’un module n’entraîne pas le besoin de redéployer un autre module) : évolutivité et maintenabilité optimales, réduisant le time to market
• Des applications sans état (avec la possibilité d’arrêter ou redémarrer une instance de l’application sans impacter les utilisateurs) : haute disponibilité et support de la montée en charge automatique, réduisant au maximum les risques d’indisponibilité
• Des domaines de responsabilité clairement établis : Chaque application est responsable d’un domaine fonctionnel minimal et cohérent, éliminant les doublons de fonctionnalités entre applications, permettant la réutilisabilité des services et la construction de référentiels métiers par domaines fonctionnels à l’échelle de l’entreprise.

La granularité et le périmètre des applications doivent être revus et pensés selon une vision Domain Driven Design (DDD) pour répondre efficacement à ces enjeux.

Les Microservices : une rupture technologique ?

Il existe de nombreux moyens de mettre en œuvre une Architecture Microservices, mais ce serait une erreur de ne pas se baser sur les technologies du moment, pensées et réalisées pour répondre précisément aux principes que nous venons d’énoncer.

Par exemple, les applications d’une Architecture SOA tournent généralement sous des serveurs d’applications (Websphere, JBoss, Tomcat, etc.) sensés garantir une homogénéité des pratiques d’administration et d’exploitation (configuration des Datasources, des logs, des URLs de ressources externes, monitoring de l’application, administration). En Architecture Microservices, on va privilégier la construction d’applications autonomes (exécutables sans conteneur d’application), basée sur des frameworks tels que Spring Boot, pour bénéficier au maximum des capacités des orchestrateurs de conteneurs comme Kubernetes telles que l’autoscaling (l’adaptation du nombre d’instances disponibles d’un service en fonction des ressources consommées à un instant T). Ces applications autonomes apportent la promesse d’arrêts/relances en un temps réduit et d’une réduction des ressources physiques consommées.

De la même manière, un ESB centralisant tous les échanges inter applicatifs, pierre angulaire de la SOA, sera repensé pour être remplacé par des Microservices d’orchestration formant ensemble des chorégraphies de services s’adaptant aux contextes des messages échangés. On ne construit plus une Architecture figée pensée en amont, mais un SI s’auto-adaptant aux évolutions rapides du marché et du SI. C’est l’ensemble des interactions entre les applications qui devient Agile.

Cette nouvelle conception nécessite également de nouveaux outils de monitoring et en premier lieu un agrégateur de logs. C’est grâce à cet outil que l’on obtient une vue globale du fonctionnement du SI, basé sur l’historique réel des échanges inter applicatifs.

D‘une Architecture à l’autre : quelle transition ?

Avant tout, il faut souligner ce point : la transition d’une Architecture SOA à une Architecture Microservices n’a aucune raison de se faire dans la douleur.

Comme rappelé en introduction, tous les principes d’Architectures structurant les Microservices existaient déjà d’une certaine manière dans la SOA. La rupture de ce point de vue est surtout technique, avec une série d’outils modernes plus adaptés à ce nouveau contexte.

Une Architecture hybride SOA (pour le legacy)/Microservices (pour les nouveaux besoins) permet de gérer cette transition technologique en douceur sans prendre de retard technique sur l’enjeu principal de la DSI : répondre de manière fiable et Agile aux besoins métiers de demain tout en garantissant la stabilité et l’évolutivité du Système.