Si vous souhaitez évoluer, la question est plutôt de savoir quelles langues ne pas utiliser.
N'utilisez pas Ruby, en particulier Rails. Ruby on Rails en particulier est si lent que la gestion de la montée en charge peut coûter 100 fois plus cher.
Un conseil important: N'utilisez aucun langage qui ne prend pas en charge les types statiques. Les types statiques sont importants pour vous aider à gérer la complexité dans n'importe quel système.
Au-delà de cela, vous pouvez choisir TypeScript avec Node.js, Go, Java ou même C ++ et php 7+. Il existe d'autres options, mais celles-ci sont les plus populaires, et la popularité est importante si vous voulez trouver facilement des personnes qui peuvent travailler sur votre service.
Go et Node.js (avec TypeScript) sont probablement les environnements les plus productifs de cette liste. l'architecture de Node.js présente un grand avantage par rapport à Apache. Traduction: Le code sera fait plus rapidement si vous avez un développeur compétent qui utilise un langage productif.
La vraie question est de savoir si vous voulez gérer 1 millions d'utilisateurs en simultanés ou 1 millions d'utilisateurs occasionnels (par jour), avec seulement quelques milliers en même temps?
Un développeur qualifié utilisant l'un des languages ci-mentionnés pourrait écrire un serveur qui gérerait quelques milliers d'utilisateurs simultanés pour presque rien, et sans infrastructure de mise à l'échelle spéciale (au-delà de l'utilisation de bases de données gérées, par exemple Amazon DynamoDB ou RDS).
Si vous regardez 1 million d'utilisateurs simultanés, cela dépend beaucoup des besoins exacts de votre application. Contrairement à ce que d'autres pourraient prétendre, vous ne pouvez pas vous attendre à ce que n'importe quel langage ou design soit évolutif en «jetant simplement plus de matériel sur le problème». Mis à part les coûts potentiellement extrêmes, la contention accrue des bases de données partagées peut en fait entraîner votre service dans une analyse si la conception n'est pas correcte.
Et c'est la clé. Vous avez besoin d'une personne expérimentée dans l'optimisation et la conception architecturale du serveur afin de ne pas vous retrouver avec une catastrophe de mise à l'échelle.
J'ai travaillé sur le projet de moteur de recherche Deepindex dont l'objectif était de pouvoir répondre au requêtes de 10 000 utilisateurs en simultanés (soit environ 10 M de visites par jour). Le client a dû mettre à disposition les ressources nécessaires pour acquérir autant d'utilisateurs. Quand j'ai commencé, il y avait déjà des problèmes de performances avec une centaine d'utilisateurs. Ensuite, avec l'optimisation, ça s'est devenu plus rapide et pouvait en gérer quelques milliers. Mais après quelques mois de travail et en révisant l’architecture, nous avons pu monter une mise à l'échelle à 1M.
Par contre avec le projet BestofChess où on devait répondre aux requêtes des internautes mais en même temps à celles de l'app mobile Chess Training free, Node.js avec du Javascript basé sur la frameword React JS était largement suffisant. Nous avons pu tout géré sur un seul serveur.
Et plus que le «bon» langage, vous avez besoin du bon plan et de la bonne architecture. Vous ne pouvez pas choisir votre équipe de développement uniquement en fonction du langage de programmation. Vous avez besoin d'un architecte senior qui peut guider le projet.
Si vous ne me croyez pas, regardez simplement la gamme de références de performance du framework. Dans certains cas, il existe une plage de variation de performances supérieure à 1000 fois entre deux cadres, même lorsque les deux cadres utilisent C ++. C'est une différence entre 100 $ / mois et 100 000 $ / mois en coûts de serveur, même si les deux serveurs utilisent le même langage le plus rapide.
En résumé, le plus important est de choisir la bonnne architecture.
