11 private links
Ca ressemble à un sujet que je prépare très sérieusement
Très bon article sur ces sombres histoires de haute disponibilité, et sur ce qu'elles peuvent réellement signifier quand on bâtit des systèmes complexes.
Gregor Hohpe est extrêmement intelligent et ses interventions sont souvent très enrichissantes. Celle-ci me paraît toutefois souffrir de trop de hauteur de vue ...
Ca se conférence, ça, non ? Je lis l'article, et je me dis qu'il est parfaitement vrai et totalement faux.
C'est exactement ce que je dis dans chacune de mes interventions
Une discussion très intéressante sur les différentes acceptations du rôle d'architecte.
Encore un système événementiel pour Postgres. Manifestement, ça doit être facile.
Un très bon site dédié aux problèmes liés à la mise en place d'une architecture événementielle à l'échelle d'un système d'information. La plupart des questions posées sont très justes.
Encore un slide à ajouter dans ma présentation de mercredi prochain
Evidement que je suis d'accord avec Gregor Hohpe ! aider les développeurs à débugger est utile pour les développeurs (parce qu'on apporte de l'expérience et un regard différent) mais aussi pour les architectes (parce qu'on voit concrètement le système qu'on étudie habituellement de façon abstraite)
J'ai vu cet excès de microservices il y a peu, et c'est une vraie douleur à maintenir ... quand ils sont mal définis (et les microservices sont très souvent mal définis)
Un moteur de recherche de mèmes utilisant ElasticSearch (évidement) mais aussi une ferme d'iPhones utilisés comme OCR (parce que Tesseract, ça marche moyennement en fait)
Je n'ai lu que le début de la discussion, et je sais qu'il faut que je la lise en entier, mais rien que les trois premières réponses lues sont fascinantes
L'article n'est pas vraiment surprenant pour moi, mais il annonce clairement pourquoi la plupart du temps les microservices sont une mauvaise idée. Et ça vaut toujours la peine de le rappeler.
Un guide bien complet sur la documentation d'architecture. Ca va me servir avant la fin du mois ;-)
Je n'ai que rarement vu ou lu quoi que ce soit articulant aussi bien les cartes de Wardley, le DDD, les team topologies dans le but de livrer vite et bien. C'est un présentation incroyablement instructive.
Des conseils utiles quand on est en position d'influence
Ce que dit Simon Brown est toujours intéressant. Cette présentation là est vraiment fascinante dans ce qu'elle dit sur les dérives dans la mise en oeuvre de l'agilité, ou l'incapacité des équipes à comprendre ce que peut être un diagramme d'architecture ayant du sens. A voir pour tous les architectes applicatifs. (je retiens d'ailleurs l'idée de scorer les diagrammes/modèles pour pouvoir les améliorer).
Oh, j'aime vraiment beaucoup cette idée d'architecte qui partage le savoir, plutôt qu'un architecte qui code.
Une liste de conseils "de bon sens" (je me méfie beaucoup du bon sens, il fait brûler les sorcières). Les conseils qui sont donnés ici sont avant tout des conseils de pragmatisme : résolvez des problèmes clairs, et clairement exprimés, plutôt que de vous enfoncer dans des généralités insolubles.