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 ...
C'est une satire assez drôle, non ?
OK, donc nos collègues d'Octo s'autorisent également à dire que les architectures microservices ne sont pas des panacées. Bien.
Oh ben tiens je me posais la question la semaine dernière, pour déployer deux composants Spring dans le même conteneur. Et effectivement, l'exemple de Nicolas n'est pas très bon, j'aurais plutôt mis deux jeux de fonctionnalités différents.
Une bonne présentation de pattern d'architecture. Bon, celui-ci est une vision assez raisonnable du microservice, en plus.
Faut que je résiste à mon envie d'en faire un sticker géant, parce que ça illustre quand même beaucoup trop bien le concept de microservices
J'aime beaucoup cet article qui aborde les microservices et le TDD sous un angle que je n'avais pas envisagé : la promesse d'une simplification qui résoudrait tout.
Le moment où on va repasser aux monolithes en tant qu'architecture applicative utile sera vraiment chouette, parce qu'il bénéficiera des leçons apprises des microservices.
Les microservices mis en place pour des raisons dogmatiques, c'est vraiment pas terrible.
Je vois des gens faire des microservices, et franchement, c'est l'enfer : il faut démultiplier la CI/CD, superviser toutes les instances, assurer la sécurité des communications, garantir la cohérence des droits. Donc oui, les monolithes, c'est l'avenir.
Certains éléments d'architecture sont discutables. Mais dans l'ensemble, ça ressemble à ce qu'on peut faire en Java/Spring/Bidule, non ? Et ça donne une appli qui marche vite en consommant bien moins d'espace mémoire.
C'est quand même chouette quand les gens expérimentés sont d'accord, non ? Même si en l’occurrence c'est à contre-courant de la mode ...
Mouaip ... La critique du monolithe commence à ressembler à de l'authentique critique artistique ... Il va bien falloir un jour ou l'autre réévaluer nos critères de conception.
J'aurais pu l'imprimer et l'afficher sur le plateau, ça ...
Et c'est pour ça qu'il ne faut pas se précipiter vers les microservices ...
Ca y est, les premiers retours d'expérience "oulala, les microservices c'est dur" arrivent. Il était temps :-) Pour la faire courte, sans surprise, faire plein de microservices dans une seule équipe,c 'est une mauvaise idée.
Est-ce qu'il a conceptuellement raison ? Oui
Est-ce que ça fait mal ? Vous allez voir à quel point !
Tellement vrai
Cette citation pourrait donner lieu à de belles dissertations, si toutefois on réfléchissait un peu en profondeur à notre métier
Tout ça est connu, mais ca vaut vraiment la peine d'être lu.
Un projet dans la veine du C4Model dédié aux architectures de microservices.
Je disais hier en bootcamp lors d'une présentation sur Docker "les microservices sont la résolution par des dévs d'un problème d'organisation" ... pas loin (parce qu'en fait, c'est une solution d'architecture logicielle)
Les critères permettant de décider si on doit utiliser des microservices sont très intéressants
Très intéressants conseils sur le vrai sens de l'architecture microservices
Ca mérite d'être imprimé et affiché dans tous les bureaux qui parlent de microservices comme la solution à tous les problèmes ...
Ce site fournit un ensemble de patrons d'architecture pour applications microservices. C'est très cool.
J'ai déja vu ça ... Et tout le monde avait l'air content de remplacer la simplicité d'appels de méthodes par la mise en place de déploiements complexes. Comme toujours, faire compliqué, c'est simple, mais faire simple, c'est compliqué.
La justification est bien plus intéressante que le message simple.
Oh mon dieu, la service-pocalypse !
J'ai l'impression de voir ça tous les jours
Chouette ! Un serveur Java idéalement taillé pour les applications à base de microservices