Bonjour,
Ça fait plusieurs fois que je vois des startups arborer fièrement le logo de RabbitMQ ou Kafka, mais n’en ai pas encore saisi leur utilité pour mes projets…
Pouvez-vous partager ici vos cas d’utilisation de RabbitMQ ou autres systèmes de MOM svp?
L’usage que je fais des implementation AMQP comme RabbitMQ est pour la communication asynchrone entre les services.
En effet avec la tendance des architectures orientées micro-services (fortement propulsé par les géants comme Amazon ou Netflix), il est essentiel d’avoir des protocoles de communications.
Or il existe deux types de communications synchrone et asynchrone. Dans le premier cas le HTTP(s) est favorisé tandis que pour une communication asynchrone de qualité (avec fault tolerance) il est préférable d’utiliser de l’AMQP. Sachant que le but ultime c’est d’avoir le plus de communication asynchrone que synchrone.
Merci pour ta réponse et tes explications, kakawait!
Afin de me faire une idée plus précise, peux-tu m’en dire plus sur l’envergure des applications (en nombre de lignes de codes, ou traffic, budget du projet, ou type du projet) qui bénéficient réellement de ce type d’architecture?
Je ne parlerais pas de mon expérience personnelle puisqu’au niveau professionnel je ne travaille pas sur une architecture microservice pour des raisons de packagings. Je ne fais que du microservice au niveau personnel sur des projets non significatifs.
Cependant je peux te donner des pistes avec les cas d’usages de :
Between 100-150 services are accessed to build a page.
De plus je te propose ce slide qui regroupe pas mal d’information.
Après pour
Qui bénéficient réellement de ce type d’architecture
Il n’y a pas de réponse simple mais voilà mes pistes personnelles :
Premature optimization is the root of all evil (or at least most of it) in programming.
Sans oublier Jeff Atwood
Hardware is Cheap, Programmers are Expensive
Par ces citations je veux faire comprendre que parfois un refactoring complet pour changer d’architecture ou commencer avec une architecture trop complexe (telle que microservice) peut être un anti-pattern.
Il faut bien comprendre que le microservice ajoute énormément de complexité :
Le cloud facilite pas mal de chose et je pense qu’il n’est pas possible (ou difficilement) de faire du microservice sans cloud et son environement (container Docker, instrumentation Puppet ou autre, etc).
De plus, il faut aussi bien maitriser son application car le but du microservice est de pouvoir scaler qu’une partie de l’application (celle qui est surcharger) au lieu de scaler un gros block monolithique. Cela peut paraitre une évidence mais ce n’est pas toujours le cas.
Je ne fais qu’esquisser des points, et j’invite chacun à ajouter sa pierre à mon analyse. Je m’excuse par avance pour la possible confusion de mes propos, j’ai écris d’un seul jet.
Type de projet : web based on cloud
Traffic : conséquent
budget du projet : conséquent (en tout cas beaucoup plus qu’avec un développement classique)
Pour répondre à la question, dès que tu dois faire communiquer 2 serveurs il y a pas mal d’avantages à utiliser un système de messaging pour l’envoi d’ordre plutôt que de faire un post vers une API HTTP :
De manière général c’est intéressant de séparer les lectures et les écritures dans un système. Si tu identifies les évènements dans ton appli (inscription d’un nouveau user, paiement, etc) , il y a probablement des opérations qui peuvent être traitées en assynchrone (envoi de mail, déclencher un batch, lancer un traitement, etc)
A partir de là tu peux isoler des services et leur envoyer des ordres via des messages.
@Kakawait : C’est clair qu’il y a une complexité supplémentaire que tu as bien listé. Mais il ne faut pas oublier qu’une grosse appli monolitique implique d’autres difficultés : mise à jour des dépendances, maintenance et debug, gestion des conflits quand plusieurs développeur travaillent sur cette même appli, déploiement complexe
C’est beaucoup plus simple de faire évoluer et de déployer une petite appli qui a une seule responsabilité clair, et qui n’a pas besoin d’avoir connaissance du fonctionnement du reste du système.
Les micro services aident à faire scaler une appli du point de vue de la charge mais également en terme de process de dev.
Au final il n’y a pas de méthode miracle : une grosse appli est complexe, qu’elle soit découpée en micro services ou pas. Le plus important c’est de savoir où on mets les pieds, et quelles difficultés on va rencontrer avec chaque approche
Oui je n’ai listé que les désavantages car je voulais pas trop paraphraser le slide que j’ai donné ou le blog post http://martinfowler.com/articles/microservices.html. Mais comme tu le dis
Au final il n’y a pas de méthode miracle
Mais je pense aussi qu’à long terme le microservice est plus rentable, mais j’ai pas de preuve ni experience pour le prouver.
Merci pour vos réponses très instructives, les gars!
Après on peut relancer le sujet en se demandant quelle est la différence entre AMQP (RabbitMQ) et Kafka. Si je ne m’abuse Kafka n’est pas une implem de AMQP.
Je ne connais pas moi même la différence et les avantages inconvénients de chacun.
Les files de message n’ont rien de neuf et ont très longtemps été utilisés dans les archis bien avant qu’on parle de micro services. Ce serait très réducteur de ne les associer qu’à ça.
En Java, la spec JMS existe depuis 2001, des produits comme MQ series depuis 1992 et il y en a bien d’autres encore.
AMQP est plus récent (2003) et propose une plus grande richesse en terme de possibilité de routage. C’est aussi un protocole multi language (à l’inverse de JMS réservé à Java).
Kafka date de 2011, a l’inverse en terme de fonctionnalité de routage il est plus limité mais l’approche est très différente. C’est un log distribué ce qui le rend par nature idéal pour une archi distribué.
J’ai utilisé RabbitMQ et Kakfa en pro. J’ai une petite préférence pour Kafka en terme de design.