Facebook EmaiInACirclel
Cloud – big data

Améliorer les microservices Python grâce à un maillage de services AWS

Catalin Dumitras
Catalin Dumitras
Architecte Cloud

Cela fait maintenant un certain temps que vous travaillez avec les microservices Python ; vous en êtes content, mais ils ne sont pas parfaits. Vous disposez désormais de centaines de microservices, et gérer la communication entre eux est un travail à temps plein.

Si vous deviez créer un diagramme du flux d’informations aujourd’hui, il deviendrait obsolète dès le mois prochain.

Intéressons-nous à un nouveau sujet qui vous aidera à booster vos microservices sous Python en profitant de la puissance d’AWS.

Commençons par résumer rapidement les questions AWS que nous avons déjà abordées dans des articles précédents :

microservices python

Lorsqu’un problème se pose au sein de l’un de vos environnements, il n’est pas toujours facile d’en trouver la cause.

Parfois, votre service de catalogue plante parce que votre service de tarifs plante. Et votre service de tarifs plante parce que votre service ERP a crashé. (Votre système ERP n’est évidemment pas un microservice, mais un connecteur à un ERP peut en être un).

 

 

Tout l’intérêt de fragmenter votre monolithe en microservices était de permettre à vos équipes d’augmenter la vitesse en utilisant les outils et langages les mieux adaptés au projet. Autre avantage, la possibilité de faire évoluer vos composants indépendamment.

C’est comme ça : un nouvel outil peut régler 80 % de vos problèmes, mais en créera 20 % de nouveaux.

 
C’est le fameux cycle du hype de Gartner. Il peut s’avérer judicieux de bien regarder votre nouveau joujou avant de vous amuser avec – cela aura le mérite de vous préparer mentalement au processus d’apprentissage à venir.

J’en parle aujourd’hui parce que je tenais à mentionner ce que Gartner a indiqué dans son rapport « Hype Cycle for Application Architecture and Development, 2019 », publié en août 2019.

Selon Gartner, les microservices sont en train de « glisser vers l’abîme » (le creux que l’on aperçoit dans le graphique ci-dessus). J’aimerais pouvoir dire que vous et moi sommes déjà en train de gravir la pente, mais seul le temps nous le dira.

Comment pouvons-nous résoudre ces merveilleux nouveaux problèmes apportés par nos microservices Python ?
 

Observabilité

Voilà un nouveau mot à la mode (ou un ancien, tout dépend avec quelle assiduité vous assistez à des conférences).

À mon sens, l’observabilité signifie en réalité que nous avons utilisé des outils tels que :

  • Les métriques d’application et d’infrastructure

  • La journalisation d’application et d’infrastructure

  • Le traçage distribué

Tous ces outils sont centralisés dans un endroit où l’on peut facilement effectuer des recherches sur eux et les visualiser pour comprendre ce qu’il se passe dans le système (aucune mise à jour n’est nécessaire avec le nouveau debug call).
 

Ne fermez pas l’onglet !

Je ne dis pas que pour y parvenir, vous devez changer tous vos microservices sous Python. En réalité, c’est assez facile à faire si vous travaillez dans AWS.

Commençons par le commencement : si vous utilisez des microservices, il est fort probable que vous utilisiez aussi un docker. Le type d’outil est généralement moins important, car ce que je vais vous suggérer fonctionne avec Kubernetes (Elastic Kubernetes Service, si vous gérez le cluster vous-même, je vous invite à remettre en question cette pratique) et ECS (Elastic Container Service), qui est leur produit natif.

Maintenant, vous devez activer « Container Insights », un tableau de bord prêt à l’emploi qui vous donne toutes sortes d’informations sur vos microservices (CPU, mémoire, disque et réseau).

Vous disposez de ces informations sur trois niveaux :

  1. Clusters

  2. Services

  3. Tâches

Je vous invite à vous assurer que vous envoyez correctement vos journaux de conteneurs afin que CloudWatch puisse les consolider pour vous permettre de faire vos recherches sur ces journaux.

Effectuer des recherches dans des journaux est désormais bien plus simple avec « CloudWatch Log Insights », un service qui vous permet de faire des recherches dans vos journaux de manière « SQL » – inutile ainsi de payer pour un cluster Elastic Search.

Il y a bien plus à faire dans ce domaine, mais c’est un bon début !
 

Maillage de services

Il est judicieux d’envisager un maillage de services pour votre couche de communication. Au lieu de modifier chaque microservice pour ajouter des fonctionnalités qui vous apportent davantage de visibilité sur le flux de données (si vous utilisez plusieurs langages de programmation, ce n’est pas évident), vous ajoutez un maillage de services à l’ensemble.

Un maillage de services (ici AppMesh) agit comme un proxy entre l’ensemble de vos microservices Python, qui gèrent tout le trafic de communication. Voilà qui est fort pratique, puisque cela supprime la nécessité de modifier vos microservices.

Cependant, le maillage de services ne convient pas à tout le monde. Je le recommande pour les contextes suivants :

  • Un grand nombre de microservices

  • Des services présents sur plus d’une plateforme informatique (EC2, Elastic Kubernetes Services, ECS)

  • Des testing A/B

  • Des déploiements Canary

  • Des besoins en termes de contrôle du trafic

 

Envie d’en savoir plus sur les maillages de services et la manière d’améliorer vos microservices ? Regardez le replay de notre webinaire (en anglais), vous y découvrirez un exemple complet d’utilisation d’AppMesh avec les microservices Python.

 

Dans le même domaine :

Comment démarrer rapidement votre projet JAVA sur AWS ?

Comment améliorer votre projet de microservices PHP avec AWS ?

Pipelines de CI/CD sans serveur avec les services AWS pour vos besoins en DevOps


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.