Guides Essentiels
Voir tous les articles de ce guide
Conseil
Cet article fait partie de notre guide: Comprendre l'évolution des architectures applicatives

Les microservices s'apparentent-il plutôt à une architecture SOA ou MVC ?

Le concept de microservices est-il nouveau ? Est-il davantage comparable aux principes SOA ou à ceux d'une architecture MVC ? Chris Riley se penche sur la question.

Chris Riley
par
Publié le: 31 mai 2017

Du monolithe aux microservices : c'est un concept très répandu lorsque l'on étudie les pratiques de développement modernes. Mais est-ce bien nouveau ? Les architectures orientées services (SOA) ne cherchaient-elles pas à faire exactement la même chose ? Oui et non. J'examinerai ce point en détail, en comparant notamment la SOA avec l'architecture MVC.

L'approche SOA est similaire aux microservices ; tout comme ces derniers sont semblables à une architecture logicielle MVC (Model-View Controller). Les idées sont les mêmes : fragmenter les applications en composants plus petits, avec une empreinte plus réduite et plus faciles à gérer. Toutefois, la plus grande différence entre ces technologies tient à l'objet et au timing de leurs introductions respectives. L'architecture SOA est arrivée la première, puis vint l'architecture MVC et enfin, les microservices.

L'approche SOA (Service Oriented Architecture) est un terme purement logiciel. Son objectif consiste à faire appliquer un schéma de conception plus efficace en matière de développement d'applications. Mais la couverture s'arrête là. En effet, cette approche n'affecte pas l'infrastructure. Ce point est important, car les applications sont devenues si complexes qu'elles occupent l'intégralité de la pile, voire des datacenters entiers. L'idée des microservices consiste à étendre la mise en oeuvre de ces plus petites unités et techniques d'isolement à l'infrastructure, ainsi qu'à la conception des applications.

La technologie SOA concerne généralement une application distincte comprenant plusieurs services internes. C'est en cela qu'elle est, selon moi, similaire à une architecture MVC. Mais il existe une grande différence : l'architecture MVC met en place une barrière entre des composants applicatifs de trois types. Elle ne leur donne pas une pleine autonomie ; en fait, les relations sont dictées. L'approche SOA leur accorde une autonomie et ne requiert des applications que le seul partage d'un schéma. Les services sont ainsi plus portables et l'élaboration de nouvelles applications encore plus simple. Mais l'API moderne fait la même chose dans une large mesure en installant une couche de services dédiée, elle aussi, au déchargement d'une plus grande part de logique. L'approche SOA a été élaborée à une époque où les API ne se trouvaient pas là où commençait le processus de développement d'applications.

L'approche SOA est une pratique que le développeur exécute au sein d'un ou plusieurs codes applicatifs, tandis que les microservices dictent jusqu'à la structure de l'équipe et aux rôles informatiques : les équipes de développement sont cloisonnées en fonction des services qu'elles élaborent. Ce constat se vérifie également pour les applications SOA. Toutefois, dans le cas SOA, le développeur est tenu de disposer de connaissances approfondies sur chaque service. Etant donné que les microservices peuvent également servir de mécanismes de mise à disposition d'infrastructure, ils ont une incidence plus importante sur le déploiement et sur ladite infrastructure.

Microservices : une architecture d'infrastructure ET logicielle

Les microservices sont autant une architecture d'infrastructure qu'une architecture logicielle. En fait, on pourrait supposer que le code présent dans le service est élaboré selon des principes de type SOA. Toutefois, dans le cas de microservices, l'implication tient à ce que l'infrastructure sur laquelle chaque service s'exécute est indépendante des autres. Aussi son autonomie est-elle préservée sur la couche serveur autant qu’au niveau du code. Ce procédé implique également que la répartition des charges peut intervenir service par service, ce qui offre aux équipes davantage de possibilités pour optimiser les performances, comparé à la  SOA. En d'autres termes, accroître la capacité pour un service rattaché revient à lancer de manière indépendante de nouvelles instances de ce service, et ainsi à offrir une évolutivité accélérée. Cela entraîne en outre une résolution plus rapide des problèmes, car dans un tel modèle, il est très probable que des services puissent s'arrêter sans entraîner l'immobilisation de toute l'application.

Microservices : un gain en matière de déploiement

Les microservices profitent à l'infrastructure mais également aux déploiements. Ceux-ci sont plus rapides, car vous déployez individuellement différents services. Il suffit en effet de déployer uniquement les services mis à jour et non plus l'intégralité de l'application. Cette caractéristique apporte une forme de continuité dans la mise à disposition et au sein des déploiements, car les plus petites unités peuvent toutes être déployées indépendamment à moindre risque.

Autre avantage rarement évoqué, les services, s'ils sont correctement configurés et mis en conteneurs, peuvent perdurer dans n'importe quel Cloud tout en restant partie intégrante d'une application cohésive. Vous pouvez ainsi disposer d'un service qui gère les connexions des utilisateurs et s'exécute dans un datacenter Amazon de la côte Est des Etats-Unis, ce même service s'exécutant également dans un datacenter Azure en Europe. Cette flexibilité est exceptionnelle.

Mais il existe aussi d'autres points importants à prendre en compte. La gestion induite supplémentaire que requièrent les microservices par rapport à une technologie SOA est considérable. En effet, les microservices nécessitent une surveillance plus robuste, une automatisation des versions plus efficace et des équipes de développement et de gestion informatique plus disciplinées. L'approche SOA peut constituer une pratique à suivre pour le développeur, là où les microservices affecteront l'intégralité du pipeline.

L'évolution du développement logiciel repose sur des degrés d'abstraction consécutifs. L'étape suivante consiste à faire abstraction de l'infrastructure afin qu'elle ne constitue plus un obstacle. Si l'approche SOA peut être considérée comme un concept vieilli, son esprit est encore bien vivant. Il est peu probable que nous continuions à utiliser ce terme car nous considérons ces types de schémas conceptuels comme l'apanage des développeurs performants.

Toutefois, la technologie SOA s'arrête à l'application. Et sachant que la complexité des applications s'accroît, vous devez penser au-delà de cette limite. Une stratégie de microservices fait sienne l'idée que les applications sont constituées de nombreux petits composants mutuellement exclusifs, et l'étend à l'infrastructure. Dans un modèle de microservices, l'homogénéité fonctionnelle, les schémas et les ressources d'arrière-plan sont autant d'éléments qui constituent l'application.

Pour approfondir sur Architectures logicielles et SOA