binaires, je fais un changement de lib, revue de code, fusion, ça part dans le package manager, puis je mets à jour les dépendances de mes binaires en un coup (puisque monorepo)
Il n'est pas inconcevable de lister dans le package.json (ou équivalent) file:../some_other_dep
Le problème de faire comme ça et que tu créé un couplage fort, un bug dans la dépendance impacte directement tout ceux qui en dépendent de cette manière. Et le rollback devient plus compliqué.
Encore du mal à vraiment voir ce que ça m'apporte de séparer plus.
De la robustesse et de la reproductibilité. Tu n'es pas obligé de mettre à jour tes 25 services d'un coup. Chacun peut dépendre d'une version différente.
Disons que ton service A est impacté par un bug dans ta dépendance. Mais le service B n'utilise pas la fonction buguée de cette même dépendance. Tu peux donc en parfaite isolation corriger le bug dans la dépendance, mettre a jour le service A, et redéployer uniquement le service A.
Ou alors, Jean Michel qui est le mainteneur de la dépendance est en vacance. On peut rollback aisément, il suffit de corriger le package.json/pom.xml/pyproject.toml, et on n'impacte pas les autres services.
Avec ElasticSearch, c'est possible?
Avec Kibana oui. La stack ELK c'est :
ElasticSearch pour indexer
Logstash pour récupérer les logs et les transmettre dans un format unifié à ElasticSearch
Kibana pour aller grep dans le ElasticSearch
Ici le point important c'est que Logstash va transformer tes logs:
level=debug time="some iso datetime" Something happened!!!
Sera transformé par logstash (suivant ta configuration de ce dernier) en:
{"level":"debug","time":"some iso datetime","message":"Something happened!!!"}
Si tu as un second service qui log cependant :
[debug] [some iso datetime] Something happened!!!
Le document qui sera indexé dans ElasticSearch sera le même. Ainsi, l'ops n'a plus à se préoccuper du format des logs lorsqu'il va composer son grep/sed/sort, il va simplement filtrer en fonction des champs du document indexé dans ElasticSearch.
Pour ton exemple:
[info] [some iso datetime] User alice is connected
Pourrait être transformé en :
{"source":"application-foobar","level":"info","time":"some iso datetime","user":"alice","event":"connected"}
En gros, c'est comme si tu configurais le grep/sed/awk/whatever au niveau du logstash. Ainsi les données que ElasticSearch ingère sont déjà structurée, ce qui facilite le querying.
C'est overkill pour des petits setups, mais quand tu commences a compter tes services par centaines, la centralisation c'est plutôt pas mal. L'ops n'a même pas à forcément connaitre l'application, il peut directement mettre en place du monitoring de log et automatiser la notification des équipes le tout de manière dynamique.
Cette stack répond a des besoins très précis, de niche je dirais même, car tout le monde n'est pas Google.
Il faut aussi se rendre compte que l'architecture microservice répond à un besoin organisationnel, et non technique. Quand tu as 20 équipes de 4 personnes qui doivent travailler sur des aspects différents d'un même projet, le monolithe (même modulaire) ralenti tout le monde. Dans une précédente mission, l'entreprise était en cours de réécriture d'un monolithe en Java (bien modularisé) vers les microservices. Les 10 équipes sont passés de "attendre 30min après chaque commit que la CI/CD du monolithe fasse son job" à "attendre 5min après chaque commit que la CI/CD de son service fasse son job".
Et je parle pas du workflow de PR sur le monolithe avec des phrases du genre "on merge quelles PR aujourd'hui ? que je sache si je vais me prendre un café ou si je travaille".
[^] # Re: Moui... mais...
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 5.
Il n'est pas inconcevable de lister dans le package.json (ou équivalent)
file:../some_other_depLe problème de faire comme ça et que tu créé un couplage fort, un bug dans la dépendance impacte directement tout ceux qui en dépendent de cette manière. Et le rollback devient plus compliqué.
De la robustesse et de la reproductibilité. Tu n'es pas obligé de mettre à jour tes 25 services d'un coup. Chacun peut dépendre d'une version différente.
Disons que ton service A est impacté par un bug dans ta dépendance. Mais le service B n'utilise pas la fonction buguée de cette même dépendance. Tu peux donc en parfaite isolation corriger le bug dans la dépendance, mettre a jour le service A, et redéployer uniquement le service A.
Ou alors, Jean Michel qui est le mainteneur de la dépendance est en vacance. On peut rollback aisément, il suffit de corriger le package.json/pom.xml/pyproject.toml, et on n'impacte pas les autres services.
Avec Kibana oui. La stack ELK c'est :
Ici le point important c'est que Logstash va transformer tes logs:
Sera transformé par logstash (suivant ta configuration de ce dernier) en:
Si tu as un second service qui log cependant :
Le document qui sera indexé dans ElasticSearch sera le même. Ainsi, l'ops n'a plus à se préoccuper du format des logs lorsqu'il va composer son grep/sed/sort, il va simplement filtrer en fonction des champs du document indexé dans ElasticSearch.
Pour ton exemple:
Pourrait être transformé en :
En gros, c'est comme si tu configurais le grep/sed/awk/whatever au niveau du logstash. Ainsi les données que ElasticSearch ingère sont déjà structurée, ce qui facilite le querying.
C'est overkill pour des petits setups, mais quand tu commences a compter tes services par centaines, la centralisation c'est plutôt pas mal. L'ops n'a même pas à forcément connaitre l'application, il peut directement mettre en place du monitoring de log et automatiser la notification des équipes le tout de manière dynamique.
Cette stack répond a des besoins très précis, de niche je dirais même, car tout le monde n'est pas Google.
Il faut aussi se rendre compte que l'architecture microservice répond à un besoin organisationnel, et non technique. Quand tu as 20 équipes de 4 personnes qui doivent travailler sur des aspects différents d'un même projet, le monolithe (même modulaire) ralenti tout le monde. Dans une précédente mission, l'entreprise était en cours de réécriture d'un monolithe en Java (bien modularisé) vers les microservices. Les 10 équipes sont passés de "attendre 30min après chaque commit que la CI/CD du monolithe fasse son job" à "attendre 5min après chaque commit que la CI/CD de son service fasse son job".
Et je parle pas du workflow de PR sur le monolithe avec des phrases du genre "on merge quelles PR aujourd'hui ? que je sache si je vais me prendre un café ou si je travaille".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg