Bon, je vais me lâcher un peu, ca tombe sur toi, le prend pas personnellement, mais fallait pas lâcher "les microservices c'est d'la balle parce que tu peux utiliser le langage que tu veux" devant moi ce soir.
En pratique si tu veux ou doit vraiment scaler, t'as une palanquée d'utilisateurs, t'as aussi une palanquée d'ingénieurs et d'équipes différentes.
Et la t'as 2 choix: chacun fait fait fait, c'qu'il lui plait plait plait, et tu gâches 30% de tes ingénieurs a réinventer la roue (et vas y que la lib cliente pour le service discovery est maintenu dans 5 langages, et pareil pour le logging/monitoring, et les roles puppet/chef, et les quarante douze docker images différentes, et les inits scripts etc. Ah, et je parle pas des lib clients pour tes 150 microservices, hein, 8 versions différentes en 5 languages (parce que les nodeux on pas réussi a se mettre d'accord la librairie de promises a utiliser, et ya bob qui ne jure que par guice, spring c'est de la merde, alors il a forke aussi)).
Et quand un service pete, personne d'autre que sont auteur n'est capable de le debugger/reparer et tu te retrouves comme un con a devoir pager un mec a moitié bourre a 3 heures du mat' pour réparer le bordel.
Mais bon, le service est écrit en rust, c'est super cool, mais ya pas de profiler, alors on saura jamais pourquoi la machine a commence a bouffer 100% du cpu un beau matin, mais bon, on a tue la task dans mesos et relancer, et maintenant c'est bon, alors c'est cool?
Tout ca parce que chaque ingénieur est un petit flocon de neige si unique, et si important qu'il doit faire les choses absolument a sa façon sinon il trépigne des pieds et arrête de respirer. Putain de millenials, un coup de pied au cul et au lit sans dessert, voila ce qu'ils méritent.
Et ca c'est du vécu (meme le coup du le polonais bourre qui nous a remit un service en marche a 2 heures du mat en rentrant du bar), j'invente rien.
Standardiser sur un petit set de technos, c'est de l'hygiene de base quand t'as une taille un tant soit peu conséquente (on va dire 100+ ingenieurs). Et choisir des technos un minimum mature, c'est de l'hygiène de base aussi.
Le but de l'informatique c'est d'automatiser les taches a large échelle. cookie cutter, cookie cutter, cookie cutter. C'est vachement moins bandant que de se tripatouiller avec des microservices tous snowflaké a un techno particulière (ou la tendance du moment), mais c'est pas grave, on va se faire du blé, et avec ce blé on peut s'acheter un truc qui fait vraiment bander.
Disons que c'est un peu toujours le meme problème. $NEW_METHODOLOGY débarque accompagne de $NEW_LANGUAGE ou $NEW_FRAMEWORK et $HIPSTER_ENGINEER saute dessus en promettant que ca va faire resoudre tous les probemes du monde, y compris ceux qu'on a pas.
Sur le papier, ca a l'air sympa, en pratique ya de sérieux problèmes de passage a l'échelle, comme toujours, mais on les connait pas (encore), alors on s'en fout.
Au final, la plupart des vrais problèmes de fond sont humain/communication/organisationnel, les autres sont en general pas si dur que ca a résoudre avec qq ingénieurs qui savent ce qu'ils font, qu'importe la methode.
Et ca loupe pas, on passe des mois a refaire des trucs pour zero resultat, tout ca parce qu'un connard irresponsable a vendu de la poudre de perlimpinpin a des managers incompetents qui comprennent pas les problème. Au final? retour a la case depart, on a toujours des problèmes, ils sont juste un peu differents de ceux qu'on avait a la base.
Potentiellement, on peut scaler 20x, mais en fait, on le saura jamais, parce que tout ce temps passer a réécrire le backend, il a pas été passe a bosser sur le produit.
Promis mec, cette fois ci, ce langage/methodologie, c'est la bonne, ca va tout changer. On va tout révolutionner et scaler 20x cette fois.
Serieux, on dirait des héroïnomanes en quete d'un dernier fix.
[^] # Re: migre
Posté par groumly . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 10.
Bon, je vais me lâcher un peu, ca tombe sur toi, le prend pas personnellement, mais fallait pas lâcher "les microservices c'est d'la balle parce que tu peux utiliser le langage que tu veux" devant moi ce soir.
En pratique si tu veux ou doit vraiment scaler, t'as une palanquée d'utilisateurs, t'as aussi une palanquée d'ingénieurs et d'équipes différentes.
Et la t'as 2 choix: chacun fait fait fait, c'qu'il lui plait plait plait, et tu gâches 30% de tes ingénieurs a réinventer la roue (et vas y que la lib cliente pour le service discovery est maintenu dans 5 langages, et pareil pour le logging/monitoring, et les roles puppet/chef, et les quarante douze docker images différentes, et les inits scripts etc. Ah, et je parle pas des lib clients pour tes 150 microservices, hein, 8 versions différentes en 5 languages (parce que les nodeux on pas réussi a se mettre d'accord la librairie de promises a utiliser, et ya bob qui ne jure que par guice, spring c'est de la merde, alors il a forke aussi)).
Et quand un service pete, personne d'autre que sont auteur n'est capable de le debugger/reparer et tu te retrouves comme un con a devoir pager un mec a moitié bourre a 3 heures du mat' pour réparer le bordel.
Mais bon, le service est écrit en rust, c'est super cool, mais ya pas de profiler, alors on saura jamais pourquoi la machine a commence a bouffer 100% du cpu un beau matin, mais bon, on a tue la task dans mesos et relancer, et maintenant c'est bon, alors c'est cool?
Tout ca parce que chaque ingénieur est un petit flocon de neige si unique, et si important qu'il doit faire les choses absolument a sa façon sinon il trépigne des pieds et arrête de respirer. Putain de millenials, un coup de pied au cul et au lit sans dessert, voila ce qu'ils méritent.
Et ca c'est du vécu (meme le coup du le polonais bourre qui nous a remit un service en marche a 2 heures du mat en rentrant du bar), j'invente rien.
Standardiser sur un petit set de technos, c'est de l'hygiene de base quand t'as une taille un tant soit peu conséquente (on va dire 100+ ingenieurs). Et choisir des technos un minimum mature, c'est de l'hygiène de base aussi.
Le but de l'informatique c'est d'automatiser les taches a large échelle. cookie cutter, cookie cutter, cookie cutter. C'est vachement moins bandant que de se tripatouiller avec des microservices tous snowflaké a un techno particulière (ou la tendance du moment), mais c'est pas grave, on va se faire du blé, et avec ce blé on peut s'acheter un truc qui fait vraiment bander.
Disons que c'est un peu toujours le meme problème. $NEW_METHODOLOGY débarque accompagne de $NEW_LANGUAGE ou $NEW_FRAMEWORK et $HIPSTER_ENGINEER saute dessus en promettant que ca va faire resoudre tous les probemes du monde, y compris ceux qu'on a pas.
Sur le papier, ca a l'air sympa, en pratique ya de sérieux problèmes de passage a l'échelle, comme toujours, mais on les connait pas (encore), alors on s'en fout.
Au final, la plupart des vrais problèmes de fond sont humain/communication/organisationnel, les autres sont en general pas si dur que ca a résoudre avec qq ingénieurs qui savent ce qu'ils font, qu'importe la methode.
Et ca loupe pas, on passe des mois a refaire des trucs pour zero resultat, tout ca parce qu'un connard irresponsable a vendu de la poudre de perlimpinpin a des managers incompetents qui comprennent pas les problème. Au final? retour a la case depart, on a toujours des problèmes, ils sont juste un peu differents de ceux qu'on avait a la base.
Potentiellement, on peut scaler 20x, mais en fait, on le saura jamais, parce que tout ce temps passer a réécrire le backend, il a pas été passe a bosser sur le produit.
Promis mec, cette fois ci, ce langage/methodologie, c'est la bonne, ca va tout changer. On va tout révolutionner et scaler 20x cette fois.
Serieux, on dirait des héroïnomanes en quete d'un dernier fix.
</rant>