Une solution pour faciliter la réalisation et le déploiement d'applications event-driven.
Ça gère la distribution des évènements dans des queues pub/sub avec des SDKs mais aussi la partie déploiement local et production de la stack en mode IAC.
Il y a aussi une UI pour la configuration, l'observabilité, les logs, etc
Ça peut être intéressant plutôt que de partir sur une infrastructure Kafka ou Rabbit
L'histoire de l'adoption de Kafka chez Cloudflare en tant que message bus inter-services.
Ils l'ont déployé pour optimiser le développement de leur architecture micro-service (découplage) mais aussi:
- réduire les silos de données
- rendre les communications inter-services plus claires
- avoir un format de communication auto-documenté
Pour cela, ils ont notamment développé un client Kafka interne qui abstrait la plupart de la configuration et de la logique compliqué.
Le schéma de communication n'est pas JSON ou Avro (ouf!) mais l'excellent Protobuf qui en plus d'avoir une taille réduite, assure le typage fort de chaque champ afin d'identifier les breakings changes.
Niveau observabilité, le plus important pour eux est le "lag", qui est le temps entre le dernier message produit et le dernier message lu.
Cette seule métrique permet d'identifier de nombreux problèmes:
- le consumer est down
- le consumer n'arrive pas à ingérer tous les messages
- un nombre inhabituel de messages est produit
- le consumer n'acquitte plus les messages
Bref, un super retour d'expérience et pleins de bons conseils pour construire son infrastructure applicative avec Kafka.
Un article très complet sur l'API Gateway utilisé par Uber.
Ils ont développé leur propre API Gateway qui est en frontal de leurs micro-services écrits dans différents langages.
user access, etc
Les API Gateway peuvent être de simples routeurs mais peuvent aussi aller plus loin en incorporant de la logique métier, comme celle de Uber justement ("low level" vs "feature rich")
Dans le cycle de vie d'une requête, ils ont extraits 4 familles de composants:
- Protocol Manager: responsable de décoder et d'encoder (JSON, Thrift, Protobuf)
- Middleware: briques métier réutilisables (authentification, rate limiting, etc)
- Endpoint Handler: convertit la requête entrante dans le format attendu par le service backend
- Client: envoi la requête au service backend (validation, timeout, retries, etc)
Un article présentant un framework pour micro-frontend avec tout le tooling pour se simplifier la vie.
Attention car même avec Piral, gérer un ensemble de micro-frontend est beaucoup plus compliqué.
Une telle décision d'architecture doit se reposer uniquement sur un besoin d'organisation d'une grande équipe en plus petites équipes focalisée sur un domaine de l'application.
Plus d'info sur les micro-frontend https://links.aschen.tech/shaare/AuKMeA
8 fausses idées reçues lorsque l'on développe des systèmes distribués
Les microservices apportent avec eux une complexité beaucoup plus grande notamment dans la traçabilité des erreurs et le debug dans un écosystème distribué sur le réseau.
Leur utilisation ne doit être envisagé que lorsqu'il y a de gros besoins de scalabilité
gRPC est un framework pour faire du Remote Procedure Call développé par Google.
Ça utilise des Protobuf donc des messages binaires pour un maximum de performances.
Nombreuses utilisations comme communication entre micro-services mais aussi client / serveur.
Un proxy distribué conçu pour rassemblé tous le traffic d'un ensemble de micro-services et profiter d'une gestion centralisée.
C'est un logiciel plus avancé que Nginx, Traefik ou HAProxy pour servir de load balancer: automatic retries, rate limiting, circuit breaker.
Une solution complète d'observabilité est aussi intégré directement à Envoy.