[lille-devops] CR meetup de décembre
Richard
que je ne bosse pas demain, je me fend d'un petit compte rendu
nocturne !
Voilà les quelques points abordés dont je me souviens, j'ai essayé de
grouper un peu par thématique. Je laisse le soin aux experts de citer
les sources, auteurs, outils... abordés.
- Simplification du déploiement et de la maintenance des architectures
d'entreprise, notamment concernant la configuration, sur des points
généralement douloureuses : DNS, DHCP...
- Toujours sur ce même sujet, solutions pour assurer
l'intéropérabilité entre plateformes / OS
- Dérive sur les solutions intégrées vs solutions complémentaires
indépendantes, rappel de l'importance du couplage lâche qui est (à
juste titre) l'une des valeurs fondamentales du devops
Je laisse le soin à Gildas et Louis de rapporter la liste des outils
et solutions dont ils ont donné les noms vu que je n'en connais pas
les 3/4.
- Discussion sur une solution pour parser des fichiers de conf de tous
formats au travers d'un outil unique, dont le nom m'échappe. Celui-ci
est le fruit du travail d'un chercheur en informatique et s'appuie sur
un langage à automates.
- Petite digression sur le ninjutsu ;),
- Le modèle d'entreprise Bottom-Up, Agile,
- l'exemple d'Amazon et son architecture hyper massivement SOA et
Cloud. Pour générer une seule page du site Amazon, plusieurs centaines
de services peuvent être sollicités.
- Communication IPC vs RESTful.
Opportunité de l'utilisation du HTTP qui évite de réinventer la roue
(protocole assurant la fiabilité des échanges et offrant un panel
complet de fonctionnalités : cryptage, authentification, contrôle
d'intégrité, routage N vers M, balancing, ségrégation...)
Une petite page wikipedia très généraliste sur IPC qui au passage
permet d'approcher la réponse à la question qu'avait posé Valentin sur
les différentes méthodes de communication entre processes sur une même
machine : http://en.wikipedia.org/wiki/Inter-process_communication
- Dérive vers XML vs JSON, pour arriver à la même conclusion qu'à la
dernière séance : XML c'est moche, JSON c'est bien. Extension du débat
à SOAP avec le même résultat.
- Discussion sur le monitoring des applications : constat des lacunes
de toutes les solutions existantes dans l'exploitation des logs
générés en production. Gildas propose une solution permettant la
recherche heuristique d'information pertinentes (différenciation bruit/
signal automatique) au moyen de fitlre bayesiens ou d'algorithmes
issus du monde de l'IA, offrant ainsi un système évolutif et capable
d'auto apprentissage, sans exiger une configuration purement
déclarative et spécifique à chaque cas d'application.
Il ne reste plus qu'à coder ça pour le présenter au meetup de janvier.
- Citation par Gildas de quelques chiffres sur le temps moyen pris
pour plusieurs opérations typiques exécutées sur un PC local ou en
réseau (lecture cache L1/L2, coût d'une mauvaise prédiction de
branchement, d'une bascule de contexte ou d'un lock, accès RAM, envoi
d'une trame sur un réseau, accès à un fichier...). Il en ressort par
exemple qu'il est parfois moins gourmand de compresser une information
(GZip) et d'envoyer les trames sur un réseau que de faire un accès au
disque dur de la machine pour récupérer la donnée équivalente.
- La gestion de la mémoire : les arcanes du multithreading telle que
le NUMA. Gildas et Louis ont également mentionné le livre suivant :
http://www.akkadia.org/drepper/cpumemory.pdf ("What Every Programmer
Should Know About Memory")
Voilà, ça doit couvrir l'essentiel de ce dont on a parlé.
Joyeuses fêtes à tous, au mois prochain !
Gildas
> Comme Gildas m'a missionné pour produire le CR du meetup de ce soir et
> que je ne bosse pas demain, je me fend d'un petit compte rendu
> nocturne !
> Voilà les quelques points abordés dont je me souviens, j'ai essayé de
> grouper un peu par thématique. Je laisse le soin aux experts de citer
> les sources, auteurs, outils... abordés.
Merci Richard pour ce compte rendu nocturne! Je rajoute 2-3 choses ci-dessous.
> - Le modèle d'entreprise Bottom-Up, Agile,
Le lean startup a aussi ete cite, en reference au fait qu'il y a
toujours limitation de ressources et qu'il faut savoir prioriser les
efforts
http://www.startuplessonslearned.com/2008/09/lean-startup.html
(ce lien m'a permis de trouver cette image
http://loci.cs.utk.edu/dsi/netstore99/docs/presentations/keynote/sld023.htm)
> - l'exemple d'Amazon et son architecture hyper massivement SOA et
> Cloud. Pour générer une seule page du site Amazon, plusieurs centaines
> de services peuvent être sollicités.
>
> - Communication IPC vs RESTful.
> Opportunité de l'utilisation du HTTP qui évite de réinventer la roue
> (protocole assurant la fiabilité des échanges et offrant un panel
> complet de fonctionnalités : cryptage, authentification, contrôle
> d'intégrité, routage N vers M, balancing, ségrégation...)
Je rajoute qu'il est souhaitable que ce protocole soit independant du
langage d'implementation et le plus simple possible.
Pour la completude, j'avais aussi cite le passage de messages facon
AMQP ou STOMP qui me sembe peut etre mieux adapte dans certains cas
(asynchrone etc).
> - Discussion sur le monitoring des applications : constat des lacunes
> de toutes les solutions existantes dans l'exploitation des logs
> générés en production. Gildas propose une solution permettant la
> recherche heuristique d'information pertinentes (différenciation bruit/
> signal automatique) au moyen de fitlre bayesiens ou d'algorithmes
> issus du monde de l'IA, offrant ainsi un système évolutif et capable
> d'auto apprentissage, sans exiger une configuration purement
> déclarative et spécifique à chaque cas d'application.
> Il ne reste plus qu'à coder ça pour le présenter au meetup de janvier.
Hehe :)
> - Citation par Gildas de quelques chiffres sur le temps moyen pris
> pour plusieurs opérations typiques exécutées sur un PC local ou en
> réseau (lecture cache L1/L2, coût d'une mauvaise prédiction de
> branchement, d'une bascule de contexte ou d'un lock, accès RAM, envoi
> d'une trame sur un réseau, accès à un fichier...). Il en ressort par
> exemple qu'il est parfois moins gourmand de compresser une information
> (GZip) et d'envoyer les trames sur un réseau que de faire un accès au
> disque dur de la machine pour récupérer la donnée équivalente.
Ces chiffres sont ceux de Jeff Dean, ingenieur emerite chez google, et
pour etre plus exact ce n'est pas gzip mais zippy, leur compresseur
maison.
http://www.regexprn.com/2009/12/numbers-everyone-should-know.html
A ce propos, je m'etais plante dans mon calcul rapide sur mes messages
de 200 caracteres envoyes sur un lien 100 mbps. Il fallait lire 50 000
messages/s.
Fort de ces chiffres tires de mon chapeau, je pretends que dans la
majorite des cas, du json non compresse suffit tout en assurant des
facilites de diagnostic etc. Si cela n'est pas assez, gzipper le flux,
passer en gigabit/s ou repartir la charge seront des options a
explorer.
> - La gestion de la mémoire : les arcanes du multithreading telle que
> le NUMA. Gildas et Louis ont également mentionné le livre suivant :
> http://www.akkadia.org/drepper/cpumemory.pdf ("What Every Programmer
> Should Know About Memory")
Merci pour ce lien!
> Voilà, ça doit couvrir l'essentiel de ce dont on a parlé.
> Joyeuses fêtes à tous, au mois prochain !
Joyeuses fetes a toutes et a tous.
Le prochain meetup (en janvier) a de fortes chances de se faire sans
moi, mais je suis sur que Thomas se chargera de l'organiser/animer :)
Gildas
Louis Coilliot
Personnellement je suis parti sur AMQP via RabbitMQ. C'est scalable,
sécurisable et rabbit est simple à prendre en main.
D'ailleurs j'ai réécris les tutos obsolètes pour python de
http://www.rabbitmq.com/getstarted.html avec la dernière
implémentation de pika, si ca intéresse quelqu'un :
https://github.com/thinkfr/ipc/tree/master/tuto
(le tuto 2 n'est pas tout à fait iso-périmètre)
REST est surement très bien mais je n'ai rien trouvé d'abouti en messaging.
J'ai donc choisi le pragmatisme.
Louis
Thomas Clavier
> REST est surement très bien mais je n'ai rien trouvé d'abouti en messaging.
>
Faut dire que c'est pas vraiement fait pour, dans REST il n'y a pas de
gestion de file d'attente, de priorité, ou autre info géré par AMQP.
Dans le monde java, REST est plus à comparer à SOAP ou Hessia, alors que
AMQP serait plus à comparer avec JMS. Pour prendre un autre exemple
j'aurais bien envie de comparer REST à l'HTTP et AMQ à XMPP ou SMTP.
Dans un cas tu as juste de l'échange à un instant T, dans l'autre toute
une gestion de boite au lettre, de priorité, etc.
--
Thomas Clavier http://www.tcweb.org
Jabber/XMPP/MSN/Gtalk : t...@jabber.tcweb.org
+33 (0)6 20 81 81 30 +33 (0)950 783 783
Thomas Clavier
> Le 21/04/2011 17:50, Louis Coilliot a écrit :
>
>> REST est surement très bien mais je n'ai rien trouvé d'abouti en messaging.
>>
>>
> Faut dire que c'est pas vraiement fait pour, dans REST il n'y a pas de
> gestion de file d'attente, de priorité, ou autre info géré par AMQP.
> Dans le monde java, REST est plus à comparer à SOAP ou Hessia, alors que
> AMQP serait plus à comparer avec JMS. Pour prendre un autre exemple
> j'aurais bien envie de comparer REST à l'HTTP et AMQ à XMPP ou SMTP.
> Dans un cas tu as juste de l'échange à un instant T, dans l'autre toute
> une gestion de boite au lettre, de priorité, etc.
>
>
Je viens de me relire et je ne me trouve pas très explicite ... je le
refait demain ... sans la bière c'est promis ;-)
Gildas Le Nadan
> Le 21/04/2011 22:11, Thomas Clavier a écrit :
>> Le 21/04/2011 17:50, Louis Coilliot a écrit :
>>
>>> REST est surement très bien mais je n'ai rien trouvé d'abouti en messaging.
>>>
>>>
>> Faut dire que c'est pas vraiement fait pour, dans REST il n'y a pas de
>> gestion de file d'attente, de priorité, ou autre info géré par AMQP.
>> Dans le monde java, REST est plus à comparer à SOAP ou Hessia, alors que
>> AMQP serait plus à comparer avec JMS. Pour prendre un autre exemple
>> j'aurais bien envie de comparer REST à l'HTTP et AMQ à XMPP ou SMTP.
>> Dans un cas tu as juste de l'échange à un instant T, dans l'autre toute
>> une gestion de boite au lettre, de priorité, etc.
>
> Je viens de me relire et je ne me trouve pas très explicite ... je le
> refait demain ... sans la bière c'est promis ;-)
Bah moi ca me parait clair et je suis d'accord :)
Ce sont des paradigmes completement différents.
En REST tu as une notion d'adresse de ressource que l'on manipule
directement alors que dans le cas d'AMQP tu as un envoi de message a un
controleur qui fera les actions.
Enfin, les deux ne sont pas forcement incompatibles, puisque REST est
plutot synchrone et bloquant alors que AMQP peut te permettre de faire
de l'asynchrone.
A+
Gildas
Louis Coilliot
Louis
Le 21 avril 2011 22:11, Thomas Clavier <t...@tcweb.org> a écrit :
> Le 21/04/2011 17:50, Louis Coilliot a écrit :
>> REST est surement très bien mais je n'ai rien trouvé d'abouti en messaging.
>>
>
> Faut dire que c'est pas vraiment fait pour, dans REST il n'y a pas de