Qu’est-ce que les microservices ?

L’architecture en microservices, aussi connue simplement sous le terme de « microservices », est une approche du développement logiciel fondée sur des services modulaires distincts et indépendants les uns des autres. 

Ces dernières années, les microservices sont devenus un choix très prisé pour la conception et le déploiement d’applications. Ils permettent de diviser les applications en composants plus petits et partiellement connectés ; ceux-ci sont testés, maintenus et déployés indépendamment les uns des autres, ce qui donne aux équipes de développement davantage d’autonomie et de contrôle créatif.

Dans cet article, nous allons expliquer ce que sont les architectures en microservices, analyser leurs avantages et inconvénients, et explorer quelques pistes sur leur évolution à venir. 

Tout d’abord, cela vaut la peine d’examiner d’autres méthodes de développement et en quoi elles sont différentes des microservices.

Qu’est-ce qu’une architecture monolithique ?

Aux premières heures du développement d’applications, le code source était entièrement intégré dans une unité de déploiement unique. C’est l’approche « monolithique ». À l’époque, si les développeurs voulaient apporter la moindre modification à une application existante, ils devaient effectuer une mise à jour complète accompagnée d’un processus d’assurance qualité spécifique, ce qui rallongeait les temps de déploiement et accroissait la charge de travail des différentes équipes impliquées. Si les mises à jour introduisaient des erreurs, il fallait mettre l’application hors ligne, la déconstruire et la corriger. 

Pour une entreprise en pleine croissance et opérant dans différents domaines d’activité, tout défaut dans l’architecture monolithique peut causer des temps d’arrêt sur la totalité de ses services — un risque qu’elle ne peut pas se permettre de prendre.

Architecture monolithique ou microservices ?

Les applications monolithiques sont développées en tant qu’unité centrale unique, où toutes les fonctionnalités partagent le même environnement d’exécution. Les microservices, quant à eux, permettent de diviser l’environnement en fonctions ou en domaines d’activité. Des équipes de développement séparées prennent ensuite la responsabilité de chaque service.

Qu’est-ce qu’une architecture orientée services ?

L’architecture orientée services (SOA, Service-Oriented Architecture) est apparue en réaction à ces inefficacités. La SOA structure les applications en composants séparés qui communiquent via un ESB (Enterprise Service Bus), qui fournit une logique métier à l’aide d’un langage de modélisation de processus métier (par exemple, BPEL). Chaque service est organisé autour d’un processus métier spécifique et adhère à un protocole de communication commun basé sur XML (par exemple, SOAP) pour le partage via l’ESB. 

Tandis que la SOA permet aux développeurs de créer, de tester et d’affiner chaque service comme il se doit, la lourdeur du protocole SOAP et des données utiles XML limite la technologie requise pour prendre en charge tous les cas d’usage. L’ESB représente aussi un point de défaillance unique pour le système. Les problèmes liés à l’ESB peuvent interrompre la suite d’applications, ce qui amoindrit les avantages d’un cycle de développement rapide.

SOA ou microservices ?

Tandis que les composants SOA communiquent entre eux à l’aide d’un ESB, ce qui crée un point de défaillance unique, les microservices utilisent les API pour communiquer entre eux.

Le rôle des API

En 2014, les microservices ont acquis une énorme popularité après la publication de « Microservices », un article fondateur de James Lewis et Martin Fowler. Les auteurs y définissent en détail l’architecture en microservices en décrivant son évolution à partir de la SOA : en tant qu’alternative à l’ESB, les composants des microservices communiquent entre eux via des API, ce qui autorise l’intégration avec des applications tierces. 

La même année a vu la publication de Spring Boot, framework open source important basé sur Java, qui permet de créer des microservices et offre un moyen plus rapide de développer des applications. La sortie de Spring Cloud 1.0 a achevé de cristalliser la popularité des microservices. Avec cette nouvelle version, les communautés de développeurs Spring et Java ont pu accéder aux principes d’architecture que Netflix a adoptés avant tout le monde.

Microservices et API

Les microservices relèvent d'un type d’architecture de développement qui permet de déléguer des fonctionnalités à des systèmes tiers. Et les API sont les éléments qui permettent à ces microservices de partager des informations entre eux. Elles servent de portes d’entrée par lesquelles les développeurs internes et externes peuvent accéder aux données d’un microservice ou utiliser ses fonctionnalités.

De nombreuses entreprises de premier plan sont fondées sur les microservices, et elles exploitent l’économie des API et les communautés de développeurs pour offrir des services avancés et hautement intégrés. Par exemple, une application VTC pourra utiliser les API Stripe pour les paiements, Google Maps pour la technologie de cartographie et Twilio pour l’envoi de SMS. 

Au moyen des API, l’architecture en microservices donne aux développeurs l’opportunité de déléguer des fonctionnalités et d’enrichir leurs applications avec des services d’experts du secteur. Dans l’exemple d’architecture en microservices ci-dessus, la société peut utiliser les API Okta d’authentification et d’autorisation pour intégrer la gestion des identités et des accès dans son application.

Comment une architecture en microservices fonctionne-t-elle ?

S’il n’existe aucun modèle ou style universel, de nombreux microservices partagent les caractéristiques suivantes et fonctionnent donc de façon similaire :

  • Composants multiples — Chaque service individuel de la structure peut être déployé, affiné et redéployé de façon indépendante sans compromettre l’application dans son ensemble.
  • Structurés autour d’entités ou de départements de l’entreprise — Les microservices sont généralement axés sur les capacités et priorités métier. Chaque équipe assume la responsabilité de faire fonctionner un produit ou un service spécifique et doit donc, pour ce faire, incorporer un mélange de compétences interfonctionnelles. Ce fonctionnement diffère radicalement du développement monolithique, où chaque équipe se concentre sur une fonction de la suite d’applications.
  • Routage simple — Les microservices utilisent des API comme moyen léger de recevoir et de traiter les requêtes, puis d’envoyer les réponses. Cela évite de devoir utiliser les ESB, trop complexes et souvent fondés sur des systèmes avancés pour le routage des messages et l’application de règles métier.
  • Décentralisation — Les microservices incorporent une variété de technologies et de plateformes, ce qui les rend inadaptés à une gouvernance centralisée. Comme les développeurs de microservices créent des outils dans le but d’aider à résoudre des problèmes, ils ont tendance à considérer favorablement la gouvernance décentralisée. La gestion décentralisée des données, où chaque service gère sa propre base de données, convient aussi parfaitement aux microservices.

Quels sont les avantages des microservices ?

L’architecture en microservices apporte une grande variété d’avantages à votre processus de développement, notamment :

  • Agilité — Une petite équipe indépendante de développeurs prend la responsabilité de chaque service. Chaque équipe peut ainsi agir de façon autonome et mettre à jour plus vite le service dont elle est responsable, ce qui réduit le cycle de développement.
  • Évolutivité — Chaque service étant un réseau de petits composants, il peut être mis à l’échelle indépendamment des autres afin de continuer à offrir la fonctionnalité qu’il prend en charge. Cela aide les équipes à évaluer avec précision le coût d’une fonctionnalité, à planifier les mises à jour en fonction des besoins d’infrastructure et à assurer la disponibilité si un service atteint un pic d’activité.
  • Spécialisation — Chaque microservice est conçu pour offrir un ensemble de fonctionnalités précis et résoudre un problème spécifique. À cette fin, il n’existe aucune approche uniforme de la conception de microservices. Les développeurs sont libres de choisir les outils qu’ils jugent les meilleurs pour résoudre chaque problème.
  • Déploiement facile — Comme les microservices sont modulaires et offrent une intégration et un déploiement continus, il est relativement aisé de mettre à jour le code, d’expérimenter de nouvelles idées, de lancer de nouvelles fonctionnalités et d’effectuer une restauration si des nouveautés ne fonctionnent pas.
  • Flexibilité — Les développeurs peuvent utiliser les services écrits pour certaines fonctions comme composants fonctionnels pour d’autres. Ils peuvent également utiliser des API publiques pour intégrer des fonctions de tiers (par exemple, Twilio, Okta, Stripe). Résultat : les développeurs peuvent créer de nouvelles fonctionnalités sans devoir en écrire le code de A à Z.
  • Pérennisation — Une architecture en microservices est évolutive, ce qui en fait la solution idéale pour les systèmes où il est impossible d’anticiper les types de terminaux susceptibles d’accéder à votre application. À leurs débuts, de nombreuses applications sont basées sur une architecture monolithique, puis sont progressivement remodelées sous forme de microservices qui interagissent via des API.

Quels sont les inconvénients des microservices ?

Bien que les microservices comportent de nombreux avantages, il faut prendre en compte les inconvénients potentiels :

  • Maintenance — Même si la défaillance d’un service n’affectera pas la totalité du système, le risque de dysfonctionnement pèse sur chaque service individuel. Par conséquent, les applications fondées sur des microservices requièrent une vigilance constante afin de détecter rapidement les défaillances et de restaurer les services aussi vite que possible. Il est recommandé de mener des tests de contrainte sur chaque service afin de tester sa résilience et ses capacités de surveillance.
  • Sécurité — Chaque service séparé représente un point de risque. Pour que votre application soit réellement sûre, vous devez donc protéger efficacement chaque microservice. Cela implique d’utiliser des produits comme Okta Advanced Server Access pour sécuriser l’infrastructure sous-jacente à votre application à l’aide de fonctionnalités d’authentification et d’autorisation. 
  • Gestion des identités et des accès — Avec les microservices, les utilisateurs se connectent à plusieurs API, pas à un service unique. Leurs identités sont souvent stockées dans des annuaires disparates, avec des profils dupliqués contenant des données contradictoires. Les utilisateurs doivent être authentifiés et autorisés sur tous ces environnements distribués. Même si chaque microservice est censé fonctionner de façon autonome, mieux vaut éviter de configurer la sécurité des identités au niveau de chaque composant.

Quel sera l’avenir des microservices ?

L’architecture en microservices évolue en permanence, mais les trois tendances ci-dessous semblent prédominer :

Architecture sans serveur

Aujourd’hui, les développeurs peuvent déployer du code à la demande sur la plateforme de fournisseurs d’informatique sans serveur. Autrement dit, ils n’ont plus besoin de réfléchir à la capacité du serveur, à la redondance et à l’environnement d’exécution. Ils peuvent donc créer, tester et déployer rapidement de nouveaux services, sans engager un gros investissement initial. AWS Lambda et Google Cloud Functions offrent actuellement ce type de service.

Edge computing

L’edge computing vise à améliorer les performances, à réduire la latence et à permettre aux applications fondées sur des microservices de s’exécuter avec plus d’efficacité et avec une puissance de traitement accrue. Les services sont mis à la disposition des utilisateurs au moyen de technologies avancées comme les applications monopages, ainsi que les fournisseurs de solutions CDN comme Cloudflare et Fastly.

Davantage d’opportunités de créativité

Les architectures en microservices sont compatibles avec le développement et la réitération collectifs. À mesure que l’économie des API publiques gagne du terrain et que le concept de code réutilisable par divers services prend de l’ampleur, nous pensons qu’à l’avenir, les développeurs vont pouvoir accéder à un nombre croissant de ressources qu’ils pourront utiliser pour incorporer de nouvelles fonctionnalités dans leurs applications.

Prise en main des microservices

Il existe plusieurs façons de s’atteler à l’utilisation des microservices, mais sachez que nous disposons d’une bibliothèque exhaustive en la matière, qui vous aidera à développer et à sécuriser vos applications.

 

 

Consultez les ressources ci-dessous pour en savoir plus sur les architectures en microservices et leur sécurisation :