mardi , 19 novembre 2019
Home » Articles » Quels sont les microservices ? Le développement de logiciel léger

Quels sont les microservices ? Le développement de logiciel léger

Utilisez l’architecture de microservices pour diviser les applications volumineuses en applications légères pouvant être mises à l’échelle horizontalement

Vous êtes sur des centaines de milliers de lignes de C++. De qui se moque-t-on ? Il s’agit de millions de lignes de Vectran, une variante de Fortran de courte durée créée par IBM dans les années 1970. Mais, est-ce qu’ils ne se cassent pas ? En effet, ils se cassent. Chaque fois que quelqu’un essaie d’ajouter une fonctionnalité, le problème se déclenche. Même en essayant de corriger les bugs, ça crée plus de bugs. Mais, si vous n’y touchez rien, ça continue de fonctionner.

Le problème est que l’innovation demande agilité et rapidité. Toutes les entreprises qui n’ont jamais eu à s’inquiéter de l’an 2000 dépassent de loin l’ancien logiciel lourd. Les investisseurs exigent la prochaine nouveauté. Puis, les clients arrivent en masse.

La solution consiste à laisser les monolithes de vos applications et ne plus en créer de nouveaux. Pour ce faire, utilisez l’architecture microservices, une technique qui divise les applications volumineuses en applications légères pouvant être mises à l’échelle horizontalement.

Définition de microservices

Les microservices segmentent la fonctionnalité dans des applications séparées qui sont faiblement couplées par des API RESTful. Par exemple, eBay a créé des applications de servlet Java distinctes qui géraient des utilisateurs, des éléments, des comptes, des commentaires, des transactions et plus de 70 autres éléments en 2006. Chacune de ces applications fonctionnelles logiques est un microservice.

Chaque microservice est autonome. Les microservices ne partagent pas une couche de données. Chacun a sa propre base de données et son propre équilibreur de charge. L’isolation est un composant essentiel de l’architecture de microservices. Les microservices individuels nécessitent différentes techniques de mise à l’échelle. Par exemple, certains microservices peuvent utiliser des bases de données relationnelles alors que d’autres peuvent utiliser des bases de données NoSQL.

Quels sont les avantages des microservices ?

L’architecture de Microservices divise les grandes applications monolithiques dotées d’architectures internes complexes et massives en applications plus petites et évolutives de manière indépendante. Chaque microservice est petit et moins complexe à développer, mettre à jour et déployer.

Quand vous y réfléchissez, pourquoi ces fonctionnalités devraient-elles en premier lieu être intégrées dans une seule application ? En théorie, du moins, vous pouvez imaginer qu’elles vivent dans des silos d’applications et de données séparés sans problèmes majeurs. Par exemple, si l’enchère moyenne recevait deux offres, mais que seulement un quart de toutes les ventes recevaient un retour, le service d’enchères serait au moins huit fois plus actif que l’application de compte-rendu à tout moment de la journée.

Si ceux-ci étaient combinés dans une seule application, vous allez exécuter – et mettre à jour – plus de codes que vous n’en avez plus besoin. En résumé, la séparation de différents groupes de fonctionnalités dans des applications distinctes est une solution intuitive.

En outre, lorsque vous architectez autour de l’architecture de microservices, vous bénéficiez d’avantages non évidents, tels que l’intégration de nouvelles technologies, telles que les conteneurs PaaS, Docker et Linux.

Flexibilité et évolutivité

Créer des applications à partir des microservices permet aussi à vos applications d’être plus flexibles et évolutives. Cela augmente l’évolutivité des équipes qui créent des applications. Avec le code monolithique, vous avez une grande équipe de personnes qui travaillent sur un gros morceau de code et qui se chevauchent de temps en temps. La vitesse de développement est ralentie de manière exponentielle avec la croissance du monolithe de code.

Mais, avec l’architecture de microservices, les applications sont créées par de petites équipes de développement décentralisées qui travaillent et modifient les microservices de manière indépendante. Cela facilite la mise à niveau des services et l’ajout de fonctionnalités. Le logiciel et le processus de développement deviennent plus agiles.

Les challenges des microservices

Chaque architecture a ses avantages et inconvénients. Même avec leurs avantages évidents, les architectures de microservices apportent un nouvel ensemble de problèmes difficiles à résoudre, notamment en ce qui concerne la journalisation, la surveillance, les tests et le débogage de votre application nouvellement décentralisée et faiblement couplée.

Les problèmes d’interdépendances

En cas de problème, quel microservice en est responsable ? Les interdépendances entre les microservices peuvent rendre cette question extrêmement difficile à répondre. Les microservices communiquent entre eux, généralement via des API JSON REST légères. Contrairement à leurs prédécesseurs XML-RPC et SOAP, les interfaces REST ont tendance à être définies de manière plus vague.

Ces API plus légères sont plus flexibles et plus faciles à étendre, mais elles ajoutent également une nouvelle interface nécessitant une surveillance et pouvant provoquer des bogues.

Avec les applications monolithiques, vous pouvez ajouter des points d’ancrage de débogage dans le code et parcourir logiquement chaque couche d’exécution pour découvrir les zones à problèmes. Lorsque vous traitez avec un maillage de dizaines voire de centaines de microservices distincts qui se communiquent entre eux avec des API peu définies, vous ne pouvez pas définir facilement les zones à problèmes.

Néanmoins, avec une planification minutieuse, vous pouvez surmonter ces difficultés. Il existe des outils de débogage qui peuvent aider, mais vous devrez probablement assembler vos propres solutions en vous basant sur d’autres situations partielles.

Comment les microservices sont-ils liés aux conteneurs et au PaaS ?

Il existe une idée fausse commune selon laquelle, pour utiliser des microservices, vous devez utiliser des conteneurs PaaS ou Linux. Ce n’est tout simplement pas vrai. Vous pouvez utiliser des conteneurs PaaS et Linux sans microservices, et des microservices sans conteneurs PaaS ou Linux. Aucun n’exige l’autre.

Mais, ils se complètent parfaitement. Les environnements PaaS, qu’il s’agisse de clouds publics tels que Heroku ou privés, tels que Cloud Foundry et OpenShift, sont optimisés pour l’exécution de nombreuses applications plus petites. Par contre, porter une application C++ de 3,3 millions de lignes sur une plate-forme PaaS n’aura jamais lieu.

Si vous décomposez votre application en applications plus petites, autonomes et évolutives, ces applications deviennent souvent de bons candidats pour un environnement PaaS.

Machine virtuelle versus un conteneur Linux

De même, les conteneurs Linux conviennent mieux aux petites applications sans état, telles que les microservices, qu’aux grandes applications monolithiques.

Après tout, l’absence d’état est l’une des différences les plus évidentes entre une machine virtuelle et un conteneur Linux. Les machines virtuelles peuvent être configurées pour conserver leur état, tandis que l’architecture des conteneurs Linux élimine intrinsèquement toute différence par rapport à l’image de base. Vous pouvez ajouter des dossiers avec état dans des conteneurs Linux, mais les conteneurs eux-mêmes ne les changeront pas à moins que vous ne validiez la modification.

La philosophie de mise à l’échelle horizontale de l’architecture de microservices promeut le concept d’applications sans partage et sans état. Ils ne stockent ni ne modifient le système de fichiers sous-jacent. C’est pourquoi les gens associent microservices et conteneurs Linux, car ni l’un ni l’autre ne conserve l’état.

Comment les microservices sont-ils liés à SOA ?

 

Les microservices et la SOA (architecture orientée services) ont presque la même architecture, mais il existe des différences significatives. En effet, SOA est associé à SOAP et XML-RPC, tandis que les microservices sont associés à JSON. Puis, à certains égards, le format de l’API associé est plutôt une différence esthétique.

En outre, la SOA utilise des bus de service d’entreprise, tandis que les microservices utilisent des bus de service de sous-publicage plus légers. Toutefois, le principe est similaire, voire plus léger.

La plus grande différence entre l’architecture de microservices et la SOA réside dans le fait que les microservices doivent être déployés indépendamment alors que les services SOA sont souvent implémentés dans des monolithes de déploiement.

Les microservices vous conviennent-ils ?

Il est important de se rappeler que les microservices sont une meilleure solution pour la mise à l’échelle des applications. À un moment donné, les architectures d’application monolithiques traditionnelles ne peuvent plus être mises à l’échelle. Cela arrive à chaque projet logiciel réussi. La base de données devient trop volumineuse, ou il y a trop de millions de lignes de code, ou vous ne pouvez simplement pas ajouter de fonctionnalités plus rapidement.

L’adoption d’outils d’orchestration

Si votre ancienne application n’est pas encore très volumineuse, c’est-à-dire qu’elle fonctionne toujours bien et n’a pas besoin d’être modifiée de façon importante, adopter les microservices vous rapportera très peu.

Après tout, les microservices apportent certaines bizarreries et difficultés au processus de développement. Garder tous ces nouveaux services en fonctionnement peut paraître un peu difficile. L’adoption d’outils d’orchestration déclarative tels que Kubernetes peut également nécessiter quelques ajustements. Les architectures de microservices complexes ont leur propre lexique pour couvrir tous les nouveaux modèles logiciels que vous devrez adopter.

Cependant, les microservices ne sont pas aussi intimidants que ce qu’était la SOA. En fait, les pratiques de microservices peuvent être mises en œuvre même dans les plus petits projets logiciels – et vous n’avez pas besoin de jeter tout votre ancien code pour commencer.

Les microservices ne sont pas pour vous!

Si vous avez une grosse application qui vous échappe, avec des cycles de vie de logiciel trop longs et un rythme d’innovation arrêté, les microservices sont peut-être ce qu’il vous faut. Par ailleurs, si vous débutez, il serait judicieux d’envisager de créer une application basée sur les microservices dès le début.

eBay a déclaré que l’architecture de microservices lui avait permis de se développer à grande échelle, d’améliorer l’extensibilité et la maintenabilité du code, de stimuler l’innovation rapide des entreprises, de créer une livraison plus rapide des produits et même d’améliorer la sécurité. Google, Amazon, Twitter, PayPal et Netflix ont tous vécu les mêmes expériences. La plupart de ces entreprises ont également créé des outils publics pour faciliter l’adoption de microservices.

Que vous rencontriez des problèmes de maintenance du code classique et que vous ne sachiez plus comment avancer, ou que vous commenciez avec une toute nouvelle application, il est temps d’évaluer une approche microservices pour le développement d’applications.

À lire aussi

Qu’est-ce que l’informatique sans serveur » ou « Serverless » ?

Des fonctions simples isolées facilitent le développement, tandis que l’exécution déclenchée par les événements rend …