11 private links
Cette idée d'un besoin d'orchestration plus complète de microservices me fascine et m'effraye à la fois ...
Un modèle de développement d'applications qui vous permet, indépendamment de développer des micro services ou un monolithem C'est intéressant, même si ça me rappelle assez confusément les EJB. Je note surtout que la première implémentation disponible est en Go.
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)
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.
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é ?
J'ai effectivement un curieux sentiment de déja vu, où le YAML remplace le XML
Si le sujet de l'architecture des microservices vous intéresse, cet article semble bien parti pour construire un référentiel de toutes les questions autour de ce sujet
Une série d'articles potentiellement très intéressante sur les microservices et leur coût (oui, je suis assez d'accord avec ce que je lis)
Un site raisonnablement complet sur les microservices, incluant des réponses à la plupart des questions pénibles sur ces sujets.
Donc la hype des microservices retombe, c'est bien. Ce qui sera mieux, ce sera quand l'industrie aura compris que les microservices correspondent à un cas d'usage dans lequel se trouvent très peu de projets.
Il faut que je relise ça tranquillement, parce qu'apparement la promesse serait de faciliter l'usage de systèmes distribués à grands coups de sagas, d'event sourcing, et autres méthodes "modernes"
Et ouais, les microservices, c'est pas forcément si simple ...
Dans mes bras !
Oh, des patterns de définition de microservices
Un peu d'histoire : que se passait-il dans les années 80 quand on avait une base de données relationnelle ? Des choses pas vraiment jolies, liées aux autres contraintes ... Par contre, ça explique bien l'intérêt des microservices ...
Une vision très détaillée de ces histoires d'architectures à base de microservices. C'est d'autant plus intéressant que ça met bien en avant le fait que le vrai truc complexe, c'est le passage du code à la prod.
Le problème de la simplicité, c'est que ça ne fait pas vendre un écosystème complet de solutions ... Cela dit, effectivement, le "monolithe" (le terme est incorrect), c'est simple ... et ça marche.
Cette idée de réécrire une partie d'un code en vérifiant sa qualité au fur et à mesure n'est pas si innovante que ça, mais elle est ici bien présentée.
C'est une vision bien plus intéressante que le découpage en contrôleur/service/repository dont les amateurs de Spring nous rebattent les oreilles (alors que c'est vraiment la pire organisation possible).
Peut-être un complément intéressant à l'écosystème PlantUML, mais connaissant la complexité qu'il y a à manipuler GraphViz, je crains le truc pas vraiment fiable ...