Idée con et qui ne debouchera pas forcément sur quelquechose, j’aimerai faire un thread pour partager nos APIS et micro services utiles voire trouver des idées pour en faire.
J’aime beaucoup cette philosophie de developpement, et du coup je propose un des miens :
Ce micro service prends une url, un nom de fichier d’image et la base64 d’un fichier et renvois a l’url la version compréssé de ce fichier en base64.
Je vais voir pour le deployer quelquepart bientot.
Si vous avez des micros services comme ca faites tourner.
Juste pour savoir, dans le cadre du boulot j’ai bien entendu déjà entendu parler des micro services (je bosse dans une SSII), mais je n’ai pas encore eu à en utiliser et je ne vois pas bien à quoi ça sert, quel type d’utilisation ça adresse… tu pourrais faire un petit retour sur ce que tu as mis en place dans ton exemple s’il te plaît ?
Quand on parle de microservices en entreprise, c’est une choix d’architecture, par opposition aux monolithes que l’on faisait par le passé.
Ce n’est pas la même chose que ce dont parle Bussiere (qui parle ici plutôt de partager des API), même si son code est effectivement un tout petit service, et donc un microservice.
Venant de la boite qui est un des plus gros champion des micro-service, y a tellement a dire sur le sujet pour que ca soit un truc bien et pas un cauchemar… Et au passage, si tu prend une dependence sur un micro service opéré par un random sur internet tu mérites tout ce qui t’arrives.
Un exemple de micro service, ça peut-être la logique d’un site marchand : la gestion du panier et du site sont séparés en deux applications distinctes, qui communiquent généralement par Http Rest. Ca te permet d’utiliser plus facilement des technos différentes (genre MongoDB pour un micro service et Sql classique pour l’autre), tout en permettant d’ajuster plus finement les resources. On peut imaginer que sous forte période de pression, tu veuilles augmenter le nombre d’instance de ton micro services qui gèrent les achats, mais que celui qui s’occupe du backoffice reste bien sage.
Un autre exemple : je suis en train de pousser un de mes client pour qu’on sépare son application web (API rest + backoffice + Batch) en trois process (micro service) différent, ceci afin de répondre plus finement à une probable augmentation du nombre de requète sur l’API.
APrès, comme le dit @GloP, c’est un domaine ou il y’a énormément a dire, et sans doute autant de solutions différentes qu’il n’y a de problèmes.
C’est juste une autre manière de dire : “programmer avec des contrats propres et des composants bien isoles, c’est bien” et adaptée a la programmation distribuée qui s’applique de nous jours. Apres… sans deconner, bienvenue en 1962 sur le concept un peu :). Mais comme beaucoup de choses évidentes, elles sont encore plus évidentes quand on les dit!
