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.

Comme je dis toujours, pour réécrire un système, il faut pouvoir en reproduire les fonctionnalités ... et les bugs (et souvent, les bugs sont mal connus)

Quelques rappels de bon design de base de données.

C'est une vision du rôle d'architecte que j'aime beaucoup.

Je vais garder cette citation dans un coin, parce que ça me semble une réflexion très pertinente sur ce qu'on choisit de mettre dans un diagramme ou pas.

Une belle explication de ce que doit être une stratégie d'observabilité "efficace"

C'est une vision alternative à ce que je fait dans aadarchi, mais c'est intéressant ... et assez stimulant, je dois dire.

Vous aviez déja entendu parler de ce canevas de documentation de microservices ? Ca ressemble à un mélange de CIPOC et d'openAPI. Est-ce que c'est utilisé ?

Encore un manifeste ? Oui, encore un, mais qui reprend la plupart de mes pratiques architecturales

J'ai effectivement un curieux sentiment de déja vu, où le YAML remplace le XML

Un guide de référence sur les architectures orientées données. C'est très complet.