Micro Services

Historiquement, les applications étaient monolithiques et nous pouvions utiliser une adresse IP pour accéder à un service. Avec les machines virtuelles (VM), plusieurs hôtes commencent à apparaître sur une même machine avec plusieurs applications. Les choses étaient encore similaires entre les machines virtuelles et les machines physiques, car les services étaient toujours accessibles depuis une adresse IP dédiée.

Avec les MicroServices, les choses ont changé et le monde n’était pas prêt.

Dans Mesos ou Kubernates, les applications sont divisées en plusieurs services avec de nombreux réplicats. Plusieurs services sont regroupés pour constituer une application. Les applications peuvent partager une même adresse IP et des hôtes physiques et utiliser un port différent. Elles peuvent également utiliser une IP aléatoire, des ports aléatoires et démarrer / s’arrêter à tout moment… Le changement est devenu la seule constante.

Découverte de Service (Service Discovery)

Comment pouvons-nous garder notre registre de service à jour ? Les DNS instanciés entre les serveurs ? Comment configure-t-on les passerelles ? …

Suivant la définition de Wikipedia, la découverte de service est la détection automatique des dispositifs et services offerts par ces dispositifs sur un réseau informatique. Un protocole de découverte de service (SDP, Service Discovery Protocol) est un protocole réseau qui aide à la découverte de services.

Les exigences principales sont :

• Vitesse
• Constamment à jour
• Résilient

Ce sont des exigences typiques, mais ce n’est pas suffisant :

• Arrêt des communications vers des services malsains
• Sous-ensembles, limitant le pool de tâches backend potentielles avec lesquelles une tâche cliente interagit
• La répartition de la charge, plus intelligente qu’une distribution circulaire (round robin) avec une meilleure optimisation (par exemple en fonction de la capacité de l’hôte, des voisins, des responsabilités)
• Minimiser le gaspillage de ressources
• Protéger les tâches individuelles contre les surcharges sur la couche de communication (pas nécessairement dans l’application)

Proxy

Le rôle du proxy (par exemple Nginx, Marathon-lb) est de transférer de manière transparente les connexions depuis un port de service statique exposant le service au monde extérieur vers l’hôte et le port dynamiquement assigné du service contenu.

Avantages

• Seul point de changement, il suffit de mettre à jour la configuration du proxy
• Aucune dépendance dans l’application, pas besoin de mettre à jour l’application
• Équilibrage de charge avec une fine granularité

Inconvénients

• Point unique de défaillance (SPoF)
• Étape supplémentaire, expose à des attaques par interception de type Man in the Middle (MitM)
• Exigence d’un protocole commun (généralement), le proxy doit savoir à quoi ressemble un paquet, comment il doit être routé

DNS

Les enregistrements SRV personnalisés dans le DNS sont utilisés pour acheminer le trafic dans les conteneurs.

Avantages

• Pas d’étape additionnelle
• Pas de Point de défaillance unique (Single Point Of Failure - SPOF), fonctionne avec des données périmées
• Protocole indépendant

Inconvénients

• Dépendance dans l’application, si nous devons changer quoi que ce soit (par exemple, dans l’équilibrage de charge), l’application doit être reconfigurée et éventuellement redéployée
• Équilibrage de la charge locale, pas de contrôle sur la répartition de la charge, pas de prévention du déni de service
• Invalidation du cache

Maille de service (Service Mesh)

Un maillage de service est une couche d’infrastructure dédiée pour rendre la communication de service à service plus sûre, rapide, fiable, observable et gérable.

Il se concentre sur la résolution des problèmes de communication entre les conteneurs. Il traite le routage, assure le réacheminement avec dégradation progressive lorsque les services échouent et sécurise la communication inter-service . Dans les applications traditionnelles, cette logique est directement intégrée dans l’application.

À mesure que les architectures deviennent de plus en plus segmentées en de multiples applications et de multiples services intégrés aux applications, le déplacement de la logique de communication hors de l’application facilite le processus de développement et d’intégration tout en offrant des fonctionnalités plus résilientes. Tout comme les applications ne devraient pas écrire leur propre pile TCP, elles ne devraient pas non plus gérer leur logique d’équilibrage de charge, de gestion de découverte de service, ou encore leurs politiques d’expiration et renvoi. Avec le maillage de service, le code de l’application n’a pas besoin de connaître la topologie du réseau, la découverte du service, l’équilibrage de la charge et la logique de gestion des connexions.

Il est composé de deux entités :

• Sidecar
• Controlleur

Le sidecar est comme un plug-in pour un service. C’est un conteneur d’utilité qui tourne à côté d’un conteneur cible avec un couplage léger entre les deux. Un conteneur sidecar est réutilisable et peut être associé à de nombreux conteneurs. Il est responsable de :

• Découverte de service
• Bilan de santé, inscriptions / désinscriptions
• Routage et équilibrage de charge : lorsque deux services ont besoin de parler, ils parlent au sidecar
• Authentification et autorisation (AuthN/Z), refusant de créer des connexions
• Abstraction de protocole, chiffrement TLS transparent, mise à niveau HTTP/1 vers HTTP/2
• Métriques / traçage, taux de réussite, volumes de demandes et latences

Le contrôleur est le cerveau du système, responsable de la gestion et de la configuration des proxys pour acheminer le trafic, ainsi que de l’application des politiques à l’exécution. Il rassemble les données du sidecar, obtient toutes les informations et informe les sidecars sur la façon dont ils doivent se comporter, parle au planificateur sur les instances en cours, … Il prend également en charge les déploiements.

Avantages

• Pas d’équilibrage de charge
• Aucune politique de rupture de circuit / répétition
• Pas besoin de traçage externe

Au moment de la rédaction de ce document, Linkerd et Istio sont deux projets Open Source considérés comme arrivés à maturité.

Linkerd peut fonctionner sur Kubernetes, DC / OS et un cluster de machines hôtes. Il fait partie de la Cloud Native Computing Foundation, est construit sur Finagle et peut utiliser gRPC. Istio fonctionne actuellement uniquement sur Kubernetes. Dans Istio, le conteneur sidecar est appelé Data Plane (basé sur le proxy de service Envoy) et le contrôleur est appelé Plane Controller.