Je mettrais pas mesos dans le tas du "nouveau qui brille juste pour le plaisir de reinventer la roue" (aka rien a voir avec node, go et consorts).
Ca resoud le probleme de la creation de vm, qui est chiant a resoudre, de l'utilisation des ressource, et ca te resoud le probleme de l'immutabilite de ton environnement.
Dit autrement, ca rend tes deployments vachement plus simple et plus robuste (enfin, sous reserve que les devs comprennent les concept d'ephemeralite du cloud, mais ca c'est pas un probleme de mesos). Pour maintenir une webapp a l'ancienne (pur chef) et un consumer kafka dans mesos, mesos est beaucoup moins prise de tete. Et surtout, vachement plus self service.
Apres, oui, c'est pas utile dans tous les cas. Ca vient de chez twitter, c'est designe pour repondre a leur modele:
- tres grand nombre de deployements quotidien (non pas que chaque webapp est deployee 20 fois par jour, mais quand t'as 50+ services, tu tapes vite dans la dizaine/centaine de deployments par jour)
- robustesse dans un environement a la aws ou tes vm peuvent canner sans crier gare
- grande utilisation des ressources quand tes webapps sont finalement tres peu cpu bound (c'est quand meme souvent le cas dans le consumer facing web)
- environnement ou les equipes sont distribuees et independantes (les ops peuvent se concentrer sur le gros cluster mesos et l'infra en generale plutot que de creer des vms en permanences pour les equipes de dev)
Mesos c'est utile si t'as des centaines d'instances qui ont besoin de relativement peu de ressources. C'est plus facile de demarrer 20 conteneur a 0.1 cpus sur 4 vms que de demarrer 20 vms a un coeur chaque.
Apres, oui, c'est jeune, et c'est instable (btrfs qui deadlock a donne du fil a retordre a l'equipe qui gere ca).
Mais c'est pas un enieme reecriture de concepts vieux de 15 ans (genre node.js, qui en plus est serieusement a la traine face a jaxrs2).
Ca repond a un reel probleme qui est mal resolu avec des solutions off the shelf, ou doit etre resolu avec un developement custom un interne.
Lle tout dans un domaine qui est tres jeune et se cherche encore (infrastructure automation). C'est bleeding edge, clairement, mais c'est pas du fashionista.
[^] # Re: Cool attitude
Posté par groumly . En réponse au journal Qui fait des trucs "cools" en France et en Europe?. Évalué à 2.
Je mettrais pas mesos dans le tas du "nouveau qui brille juste pour le plaisir de reinventer la roue" (aka rien a voir avec node, go et consorts).
Ca resoud le probleme de la creation de vm, qui est chiant a resoudre, de l'utilisation des ressource, et ca te resoud le probleme de l'immutabilite de ton environnement.
Dit autrement, ca rend tes deployments vachement plus simple et plus robuste (enfin, sous reserve que les devs comprennent les concept d'ephemeralite du cloud, mais ca c'est pas un probleme de mesos). Pour maintenir une webapp a l'ancienne (pur chef) et un consumer kafka dans mesos, mesos est beaucoup moins prise de tete. Et surtout, vachement plus self service.
Apres, oui, c'est pas utile dans tous les cas. Ca vient de chez twitter, c'est designe pour repondre a leur modele:
- tres grand nombre de deployements quotidien (non pas que chaque webapp est deployee 20 fois par jour, mais quand t'as 50+ services, tu tapes vite dans la dizaine/centaine de deployments par jour)
- robustesse dans un environement a la aws ou tes vm peuvent canner sans crier gare
- grande utilisation des ressources quand tes webapps sont finalement tres peu cpu bound (c'est quand meme souvent le cas dans le consumer facing web)
- environnement ou les equipes sont distribuees et independantes (les ops peuvent se concentrer sur le gros cluster mesos et l'infra en generale plutot que de creer des vms en permanences pour les equipes de dev)
Mesos c'est utile si t'as des centaines d'instances qui ont besoin de relativement peu de ressources. C'est plus facile de demarrer 20 conteneur a 0.1 cpus sur 4 vms que de demarrer 20 vms a un coeur chaque.
Apres, oui, c'est jeune, et c'est instable (btrfs qui deadlock a donne du fil a retordre a l'equipe qui gere ca).
Mais c'est pas un enieme reecriture de concepts vieux de 15 ans (genre node.js, qui en plus est serieusement a la traine face a jaxrs2).
Ca repond a un reel probleme qui est mal resolu avec des solutions off the shelf, ou doit etre resolu avec un developement custom un interne.
Lle tout dans un domaine qui est tres jeune et se cherche encore (infrastructure automation). C'est bleeding edge, clairement, mais c'est pas du fashionista.