Passez vos Microservices Python au Niveau Supérieur avec AWS

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 :

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 :

Clusters
Services
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.