Pour la scalabilité, Python (et probablement ruby et PHP) sont à la ramasse au bout d'un moment
-_-'
Ha, on est toujours dans le troll ? Nan parce qu'on est samedi, mais je sais plus en fait.
scalables se résolvent par de l'architecture, aussi bien côté code qu'infra
Scaler, dans la grande majorité des cas, n'est absolument pas un problème de langage, runtime, vm.
Scaler aujourd'hui c'est de l'archi, tout existe pour que ça scale. Allez, je prend des exemples réels. J'ai une app Rails dont une grosse partie de son temps de traitement est dédié à manipuler des images et faire des vidéos. Ha c'est sur que de base ça scale pas beaucoup. Ok, je peux viser le scale vertical, prévoir une plus grosse machine qui va utiliser imagemagick et qui va être plus performant. Ou alors je sort chaque brique qui pose problème et je résous chaque problème indépendamment. Générer des miniatures, cropper des images ? J'ai 1000 Lambda chez Amazon qui n'attendent que ça. Le jour où attendre 1.5s pour générer simultanément 1000 traitements d'images (une image source, 3 images en sortie) j'en demanderai plus à Amazon, mais j'ai de la marge pour le moment... Ha oui, c'est du js. Je dois encoder des vidéos. J'ai un service Go couplé à de l'elastic transcoder. Je dois scaler ? Mon service Go est totalement stateless, je peux en déployer absolument autant que je veux pour réduire l'attente si j'ai besoin.
Mon app pourrait être en ruby, en python, en java, en dotnet, en brainfuck, ça ne change absolument rien niveau scalabilité. Elle sert à faire qq calculs et répondre aux demandes front. Tous les gros traitements sont séparés dans des unités qui scales chacune de manière appropriée. Et bien évidemment mon app rails est en cluster derrière un load balancer. Bref la ramasse elle est où ?
[^] # Re: migre
Posté par CrEv (site web personnel) . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 10.
-_-'
Ha, on est toujours dans le troll ? Nan parce qu'on est samedi, mais je sais plus en fait.
Scaler, dans la grande majorité des cas, n'est absolument pas un problème de langage, runtime, vm.
Scaler aujourd'hui c'est de l'archi, tout existe pour que ça scale. Allez, je prend des exemples réels. J'ai une app Rails dont une grosse partie de son temps de traitement est dédié à manipuler des images et faire des vidéos. Ha c'est sur que de base ça scale pas beaucoup. Ok, je peux viser le scale vertical, prévoir une plus grosse machine qui va utiliser imagemagick et qui va être plus performant. Ou alors je sort chaque brique qui pose problème et je résous chaque problème indépendamment. Générer des miniatures, cropper des images ? J'ai 1000 Lambda chez Amazon qui n'attendent que ça. Le jour où attendre 1.5s pour générer simultanément 1000 traitements d'images (une image source, 3 images en sortie) j'en demanderai plus à Amazon, mais j'ai de la marge pour le moment... Ha oui, c'est du js. Je dois encoder des vidéos. J'ai un service Go couplé à de l'elastic transcoder. Je dois scaler ? Mon service Go est totalement stateless, je peux en déployer absolument autant que je veux pour réduire l'attente si j'ai besoin.
Mon app pourrait être en ruby, en python, en java, en dotnet, en brainfuck, ça ne change absolument rien niveau scalabilité. Elle sert à faire qq calculs et répondre aux demandes front. Tous les gros traitements sont séparés dans des unités qui scales chacune de manière appropriée. Et bien évidemment mon app rails est en cluster derrière un load balancer. Bref la ramasse elle est où ?