Dans un contexte où les équipes de développement ont besoin de plus de flexibilité, d’évolutivité et de rapidité, l’obsolescence des modèles monolithiques traditionnels de conception de logiciels est aujourd’hui indéniable. De ces exigences du paysage informatique actuel ont d’ailleurs émergé deux options efficaces de conception et d’exécution d’applications complexes à grande échelle : l’architecture orientée services (SOA) et les microservices.

Mais quel modèle choisir ? Si à première vue ces approches peuvent sembler très similaires, elles comportent pourtant des différences notables, qui devraient aider votre équipe de développement à s’orienter vers la solution la mieux adaptée à votre entreprise. Dans cet article, nous explorerons chacun de ces deux modèles, ainsi que leurs principales différences, et aborderons certains cas d’usage avancés.

SOA et microservices : présentation

Avant d’aborder les différences entre SOA et microservices, commençons par définir leurs points communs. Ces deux modèles présentent les caractéristiques suivantes :

• Ils décomposent les applications complexes et à large portée en sous-éléments plus flexibles.
• Ils offrent une évolutivité accrue permettant d’accélérer le développement et le déploiement des applications.
• Ce sont des modèles de développement agiles qui se basent sur un environnement cloud ou hybride.

En quoi se distinguent-ils ? SOA et microservices présentent en réalité des différences majeures en termes de portée, d’architecture, de gouvernance et de communication. De quoi nous donner suffisamment de matière pour une analyse comparative et approfondie de chaque modèle.

Qu’est-ce que l’architecture orientée services ou SOA ?

L’architecture orientée services est un modèle de développement de logiciels basé dans le cloud au sein duquel les composants d’application sont divisés en modules de services distincts. Plus petits et plus flexibles que les applications monolithiques, ces modules sont plus simples à exploiter.

Services SOA

La SOA fournit quatre principaux types de services :

• Les services fonctionnels, ou services métier, qui concernent les applications ou opérations métier.
• Les services d’entreprise, qui sont utilisés pour implémenter les fonctionnalités.
• Les services d’application, qui se rapportent spécifiquement au développement et au déploiement d’applications
• Les services d’infrastructure, qui concernent les processus backend non fonctionnels tels que la sécurité, les accès et l’authentification.

Composants SOA

Chaque service SOA est fait de trois composants :

• L’interface, qui décrit la manière dont le fournisseur de services gérera les demandes des clients.
• Le contrat, qui définit les termes de l’interaction entre le fournisseur et le client du service.
• L’implémentation, ou code de service.

Différents services SOA peuvent également être combinés pour développer des services et applications plus complexes. De manière générale, l’architecture orientée services connecte ces modules en passant par une solide couche de contrôle et de communication dénommée bus de service d’entreprise (ESB).

Découplage SOA

La structure SOA repose sur le concept de « découplage ». Dans ce modèle, les composants n’ont donc pas besoin de l’intégration point par point requise par l’architecture monolithique. Ils peuvent ainsi communiquer via l’ESB, même s’ils dépendent d’une plateforme ou d’un langage de programmation différents. Cela offre aux équipes de développement la possibilité de réutiliser des modules à d’autres fins dans l’entreprise, leur évitant d’avoir à recréer chaque composant individuel de chaque nouvelle application web.

L’inconvénient de ce procédé reste que les éventuels bogues et failles d’un composant affecteront forcément toutes les instances où il a été implémenté. Par conséquent, tout problème dans le code ou d’autres composants est ici susceptible d’avoir une incidence généralisée, dès lors que les modules sont déployés à grande échelle dans l’entreprise.

Qu’est-ce qu’un microservice ?

L’architecture en microservices est considérée comme une extension de l’architecture orientée services. Elle aussi décompose les applications de grande ampleur en plus petits composants flexibles, mais avec davantage de granularité. Par ailleurs, l’architecture en microservices organise également chaque unité autour d’une fonction métier spécifique et hautement spécialisée.

Contexte délimité

Les microservices fonctionnent selon un principe dit de contexte délimité, qui correspond à la capacité à positionner un composant et ses données en tant qu’unité autonome ou peu dépendante. En d’autres termes, les services sont découplés et fonctionnent de façon indépendante. De cette manière, si l’un des services web d’une application tombe en panne, ses autres services associés continuent de fonctionner normalement.

API

Dans le modèle en microservices, les services utilisent une interface de programmation d’application (API) pour communiquer entre eux et avec les autres composants et applications. Une fois connectés via l’API, les services distincts peuvent alors être unifiés pour créer une application plus complexe.

Orchestration des conteneurs

Du fait de l’indépendance des services et du recours aux conteneurs sur lequel repose généralement l’architecture en microservices, cette approche offre souvent davantage d’évolutivité, de portabilité et de tolérance aux pannes que les autres modèles de développement, y compris la SOA.

SOA et microservices : comment les distinguer ?

La principale différence entre SOA et microservices réside dans la portée de leur architecture. Dans le modèle SOA, les services ou modules sont partagés et réutilisés à l’échelle de l’entreprise, tandis que l’architecture en microservices est conçue sur la base de services individuels fonctionnant de manière indépendante. En résumé, la SOA s’applique à l’échelle de l’entreprise et l’architecture en microservices à celle de l’application.

Cette distinction entraîne des différences notoires entre les deux modèles :

Réutilisation / Duplication des données

Dans le modèle SOA, les développeurs réutilisent les composants pour gagner en évolutivité et en efficacité. Appliquer la même approche au sein d’une architecture en microservices conduirait en revanche à la perte d’agilité et de tolérance aux pannes, là où la réutilisation d’un composant créerait des dépendances entre services. Pour améliorer l’efficacité et maintenir un haut niveau d’indépendance, les développeurs des architectures en microservices passent donc à la place par la réutilisation du code ou la duplication des données.

Appels synchrones / Communication asynchrone

Dans le modèle SOA, les services sont mis à disposition dans l’ensemble de l’entreprise par le biais de protocoles synchrones. Le plus souvent, cela prend la forme d’API RESTful. Dans l’architecture en microservices, les appels synchrones auraient en revanche pour effet de créer des dépendances en temps réel, engendrant à leur tour la perte de fiabilité et de résilience. Pour contourner ces problèmes et préserver de hauts niveaux de performance, les développeurs privilégient donc la communication asynchrone qu’ils appliquent au moyen de techniques comme l’approvisionnement en événements ou le modèle publier / s’abonner.

Données sources / Données locales

Dans l’architecture orientée services, toutes les applications doivent pouvoir recevoir et mettre à jour des données au niveau de la source au même moment. Cela évite d’avoir à inclure des modèles complexes de synchronisation des données. Si l’on se place du point de vue de l’architecture en microservices, cette approche n’est toutefois pas idéale en raison des dépendances entre services qu’elle crée. Afin de préserver l’indépendance de tous ses services et applications, les microservices misent donc sur un accès local à toutes les données nécessaires à chaque service. Si cela crée des instances en double, et par extension complexifie l’architecture, cette méthode évite aussi les dépendances susceptibles d’entraver les performances.

ESB / API

Dans la SOA, les services sont organisés et coordonnés à l’aide d’un canal commun de communication appelé bus de service d’entreprise (ESB). Cette centralisation des communications introduit le risque de point de défaillance unique pour tous les services. Afin d’éviter le problème et de garantir l’indépendance de leurs opérations, les microservices communiquent, quant à eux, par le biais d’une API.

Tous les points abordés ci-dessus ainsi que plusieurs autres différences sont résumés dans le tableau suivant :

SOA et microservices : quelle architecture choisir pour votre entreprise ?

Les modèles SOA et en microservices présentent chacun leurs avantages et leurs inconvénients. Le choix de l’une ou l’autre architecture dépend souvent de votre cas d’usage, mais aussi de vos ressources à disposition, de votre maturité IT et des besoins de votre entreprise.

Option SOA

Les environnements d’application vastes et diversifiés ont tendance à préférer la SOA qui, grâce à l’ESB, permet de bénéficier d’une solide intégration. Cela permet aux développeurs de connecter des applications hétérogènes et une multitude de protocoles de messagerie tout en conservant l’indépendance de chaque application.

Ceci étant, les déploiements de SOA tendent à être plus lents et plus complexes que les microservices. Du fait du couplage de nombreux services entre eux, l’ajout d’un nouveau service ou d’une nouvelle fonctionnalité implique en effet, et dans une certaine mesure, le redéploiement de l’ensemble de l’application.

Voici certains cas d’usage spécifiques qui se prêtent à l’architecture orientée services :

• Mise en place de la communication entre plusieurs applications indépendantes
• Création d’un service dont le but est précisément d’être réutilisé à une ou plusieurs reprises
• Prise en charge d’une application associée à plusieurs sources de données
• Exposition de données ou de fonctionnalités à des clients externes
• Développement de fonctions sans serveur

Option microservices

L’architecture en microservices demande généralement moins de temps et d’efforts à concevoir que la SOA. Plus petits, ses services sont en effet plus faciles et rapides à déployer.

Les entreprises dont les environnements sont plus restreints et moins complexes et qui n’ont pas l’utilité d’une plateforme de communication ultrapuissante considèrent généralement que les microservices leur offrent davantage de rapidité, de flexibilité et de résilience pour un coût et une complexité moindres.

Les microservices représentent l’option idéale pour les cas d’usage suivants :

• Projets relativement simples, facilement décomposables
• Applications complexes qui ont déjà été décomposées ou peuvent facilement l’être
• Adoption de processus agiles de développement et de livraison continue
• Optimisation des ressources de cloud computing, notamment par le biais de conteneurs
• Applications qui utilisent plusieurs infrastructures, langages et technologies au sein d’un même environnement

Découvrez-en davantage sur les solutions de sécurité cloud de CrowdStrike et programmez une démonstration afin de définir ensemble celle qui convient le mieux aux besoins de votre entreprise.