Ok. Donc en gros, tu veux déployer un vrai service avec une architecture pas forcément si complexe, mais moderne.
Donc t’as besoin de pas mal de services, déployés indépendamment. Perso mon avis sur ce genre de choses, c’est que le cloud élastique à la aws/azure est parfait. Tu provisionnes uniquement ce dont t’as besoin, et tu t’évites des coûts importants en amont, le temps de construire la base.
Une fois que t’as atteint la vitesse de croisière, tu peux commencer à migrer sur ton propre hardware, mais à moins d’avoir du vrai traffic a large échelle, je vois pas trop ce que tu vas faire avec une instance 8xlarge. Commence plus petit/cheap, et voit ou ça te mène.
C’est ce que les développeurs de Facebook avaient l’habitude de faire : l’avantage de la mobilité de leur laptop, avec l’avantage de la puissance de calcul du serveur.
oui, alors, Facebook adore se faire mousser avec leurs articles "ouais, mais tu vois, à notre échelle, on peut pas faire comme les autres, alors on a développé cette techno de malade". Sauf que, effectivement, ils ont échelle de furieux, et la plupart des problèmes qu’ils rencontrent ne sont absolument pas pertinents pour la vaste majorité du commun des mortels.
Oui, je suis à peu près convaincu que vu l’infra massive de Facebook, une bonne partie de leurs ingénieurs ne peuvent pas raisonnablement développer localement.
Rappelle toi aussi que facebook a probablement plus d’ingénieurs que tu n’auras d’utilisateurs en production. On parle de milliers d’ingénieurs bossant toute la journée, sans compter la batterie de tests qui tournent en interne.
Donc, oui, dans ce contexte, c’est raisonnable d’investir pour que les inges développent à distance directement sur la même infra que leur prod, ça leur évite des soucis.
Pour le commun des mortels, j’ai vraiment du mal à voir pourquoi tu t’emboucannerais avec ça. Develope chaque service localement. Déploye dans un environment de dev pour validation. Quand ça tourne, yolo ça en prod, comme tout le monde.
[^] # Re: Un peu confus
Posté par groumly . En réponse au journal Intel = 14 nm, AMD = 7 nm, ARM = 7 nm... et mon serveur ?. Évalué à 5.
Ok. Donc en gros, tu veux déployer un vrai service avec une architecture pas forcément si complexe, mais moderne.
Donc t’as besoin de pas mal de services, déployés indépendamment. Perso mon avis sur ce genre de choses, c’est que le cloud élastique à la aws/azure est parfait. Tu provisionnes uniquement ce dont t’as besoin, et tu t’évites des coûts importants en amont, le temps de construire la base.
Une fois que t’as atteint la vitesse de croisière, tu peux commencer à migrer sur ton propre hardware, mais à moins d’avoir du vrai traffic a large échelle, je vois pas trop ce que tu vas faire avec une instance 8xlarge. Commence plus petit/cheap, et voit ou ça te mène.
oui, alors, Facebook adore se faire mousser avec leurs articles "ouais, mais tu vois, à notre échelle, on peut pas faire comme les autres, alors on a développé cette techno de malade". Sauf que, effectivement, ils ont échelle de furieux, et la plupart des problèmes qu’ils rencontrent ne sont absolument pas pertinents pour la vaste majorité du commun des mortels.
Oui, je suis à peu près convaincu que vu l’infra massive de Facebook, une bonne partie de leurs ingénieurs ne peuvent pas raisonnablement développer localement.
Rappelle toi aussi que facebook a probablement plus d’ingénieurs que tu n’auras d’utilisateurs en production. On parle de milliers d’ingénieurs bossant toute la journée, sans compter la batterie de tests qui tournent en interne.
Donc, oui, dans ce contexte, c’est raisonnable d’investir pour que les inges développent à distance directement sur la même infra que leur prod, ça leur évite des soucis.
Pour le commun des mortels, j’ai vraiment du mal à voir pourquoi tu t’emboucannerais avec ça. Develope chaque service localement. Déploye dans un environment de dev pour validation. Quand ça tourne, yolo ça en prod, comme tout le monde.