Pardon il était tôt et j'ai une aversion sans bornes pour les vm.
Petite mise en situation.
Gros site web français de vente en ligne en 2005. 6 serveurs front apache/tomcat, 3 serveurs applicatifs jboss, 2 serveurs de db postgres. Le tout backupé, redondé, monitoré, mis à jour etc. 11 serveurs Redhat à gérer.
Passage à vmware vers 2010 : 30 serveurs fronts, 15 serveurs applicatifs, 2 bdd toujours. Soit 47 vm à gérer à backuper plus les 4 esx ... Je ne ferais aucun commentaire sur l'enfer que c'est de gérer des esx et encore moins de les monitorer.
Résultat des courses mon patron vend plus de vm pour plus cher et se fait plus de thune et moi je me retrouve avec littéralement 5 fois plus de serveur à gérer, des nouvelles technos pour une stabilité pas folle à l'époque.
Je passe sur la lourdeur d'installer des vm, la bêtise du clonage, l'interface clic clic de vmware, la perte d'un quart de la prod quand un esx plante, l'ajoute de baie de stockage supplémentaire etc. Bref on est passé d'un truc simple et basique à une usine à gaz infernale.
Au final je me suis barré et le taf a été repris par des Indiens.
Dernière anecdote. En 2005 passer les patchs redhat des 11 serveurs c'était l'histoire d'une nuit. En 2013 quand je suis parti les Indiens n'avait pas le temps de passer tous les patchs n, avant la sortie des patchs n + 1. Ok la cause n'est pas tant le nombre de vm que l'incompétente générale généré par l'outsourcing. Même 5 dois plus de machine c'est 5 fois plus de taf.
A oui tout ce beau monde est tout dans un même DC, Voir tout dans la même baie ... Voir dans 4 blades dans le même châssis que d'autre client ...
Au final le client est parti ... Comme tous les autres d'ailleurs.
Aujourd'hui et depuis 2017 comment qu'on fait ? C'est la concomitance de trois technos fabuleuses et d'un fournisseur d'infra qui comprend la prod qui permet d'aujourd'hui cocher toutes les cases. Résilience, redondance, simplicité, reproductibilité et standardisation de la prod.
ovh pour l'infra. Ma prod est active/active sur 3 DC en France avec une interconnexion à 25gbps pour un peu plus de 100€ht/mois. Unique et imbattable. Si on est riche on peut faire pareil sur 3 dc autours de paris avec une latence en dessous de 1ms là ou on est autours de 10ms entre Roubaix/Graveline et Strasbourg. Mais honnetement actuellement je n'ai pas de vraiment de problème. Et si jamais ca pose problème il y a des moyens avec k8s de contourner.
l'incroyable et extra ordinaire ceph qui a changé ma vie. Le storage n'est plus jamais un problème. Ça juste marche et ça scale à l'infini.
les containers avec crio. C'est simple et efficace et ce n'est plus moi qui gère mais les dev. C'est leur responsabilité. Je ne reçois plus littéralement 50pages de packages perl/php avec la version exacte à installer sur les serveurs. Juste une image que je lance.
et enfin pour orchestrer et standardiser tout ça : kubernetes.
Pour finir en 2010 quand j'ai quitté l'opérateur de cloud ou je bossais on était 40 tech pour gérer environ 3500 devices. Un device c'est une vm, un serveur, une url, une db etc. C'est ce qu'on monitore. Aujourd'hui on est 6 tech et on en gère 5500. Et on passe le plus clair de notre temps à faire du social avec les dev que à gérer la prod. Ça juste marche tout seul. De temps en temps un serveur déconne et on le remplace, de temps en temps on a des problèmes réseau et on isole les serveurs impactés. Plus grave un DC crame. On sort juste les serveurs du k8s, on dit à ceph qu'il manque un dc et rien n'est coupé. C'est un peu le dawa pendant qq 10e de minutes mais rien n'est perdu.
En 2025 je pense que cette stack ovh + ceph + k8s est la plus simple, la moins chère et la plus résiliente possible. En tous les cas chez nous on en est très satisfait et nos clients restent :) c'est que ca doit pas être si mal.
Petit bémol cependant. K8s est un énorme changement de paradigme. Quand on a été admin sys unix pendant 25ans c'est un changement difficile. Cependant k8s en prod n'est pas une techno trop complexe. Ce n'est pas veritasfs ou oracle ou vmware :). Par contre ceph c'est piégeux, c'est vrai. Et encore avec Rook qui est l'opérateur qui gère ceph dans k8s il y a beaucoup de choses automatisées. Mais il faut quand même faire bien attention à comment sont configuré nos zones de pannes pour ne pas perdre de données en cas de problème.
Bref, k8s/ceph c'est plus simple au quotidien mais ça demande quand même certaines compétences un peu plus pointues. Et encore. J'ai eu des problèmes vraiment vicieux avec esx et encore jamais avec ceph/k8s. Il est vrai aussi que trouver des compétences sur le marché n'est pas non plus facile. Les gens qui connaissent k8s, connaissent le k8s des gafams qui ont un setup assez différent de chez noujs. C'est pour ça qu'on forme des jeunes pendant leurs études et on embauche les meilleurs à la fin.
Voilou et encore désolé pour le commentaire lapidaire, j'ai une sorte de PTSD avec les vm :)
[^] # Re: Attention aux inondations
Posté par oau . En réponse au lien "Ça fonctionne de la même façon," la ville d'Échirolles choisit un logiciel libre pour remplacer Win. Évalué à 5.
Pardon il était tôt et j'ai une aversion sans bornes pour les vm.
Petite mise en situation.
Gros site web français de vente en ligne en 2005. 6 serveurs front apache/tomcat, 3 serveurs applicatifs jboss, 2 serveurs de db postgres. Le tout backupé, redondé, monitoré, mis à jour etc. 11 serveurs Redhat à gérer.
Passage à vmware vers 2010 : 30 serveurs fronts, 15 serveurs applicatifs, 2 bdd toujours. Soit 47 vm à gérer à backuper plus les 4 esx ... Je ne ferais aucun commentaire sur l'enfer que c'est de gérer des esx et encore moins de les monitorer.
Résultat des courses mon patron vend plus de vm pour plus cher et se fait plus de thune et moi je me retrouve avec littéralement 5 fois plus de serveur à gérer, des nouvelles technos pour une stabilité pas folle à l'époque.
Je passe sur la lourdeur d'installer des vm, la bêtise du clonage, l'interface clic clic de vmware, la perte d'un quart de la prod quand un esx plante, l'ajoute de baie de stockage supplémentaire etc. Bref on est passé d'un truc simple et basique à une usine à gaz infernale.
Au final je me suis barré et le taf a été repris par des Indiens.
Dernière anecdote. En 2005 passer les patchs redhat des 11 serveurs c'était l'histoire d'une nuit. En 2013 quand je suis parti les Indiens n'avait pas le temps de passer tous les patchs n, avant la sortie des patchs n + 1. Ok la cause n'est pas tant le nombre de vm que l'incompétente générale généré par l'outsourcing. Même 5 dois plus de machine c'est 5 fois plus de taf.
A oui tout ce beau monde est tout dans un même DC, Voir tout dans la même baie ... Voir dans 4 blades dans le même châssis que d'autre client ...
Au final le client est parti ... Comme tous les autres d'ailleurs.
Aujourd'hui et depuis 2017 comment qu'on fait ? C'est la concomitance de trois technos fabuleuses et d'un fournisseur d'infra qui comprend la prod qui permet d'aujourd'hui cocher toutes les cases. Résilience, redondance, simplicité, reproductibilité et standardisation de la prod.
Pour finir en 2010 quand j'ai quitté l'opérateur de cloud ou je bossais on était 40 tech pour gérer environ 3500 devices. Un device c'est une vm, un serveur, une url, une db etc. C'est ce qu'on monitore. Aujourd'hui on est 6 tech et on en gère 5500. Et on passe le plus clair de notre temps à faire du social avec les dev que à gérer la prod. Ça juste marche tout seul. De temps en temps un serveur déconne et on le remplace, de temps en temps on a des problèmes réseau et on isole les serveurs impactés. Plus grave un DC crame. On sort juste les serveurs du k8s, on dit à ceph qu'il manque un dc et rien n'est coupé. C'est un peu le dawa pendant qq 10e de minutes mais rien n'est perdu.
En 2025 je pense que cette stack ovh + ceph + k8s est la plus simple, la moins chère et la plus résiliente possible. En tous les cas chez nous on en est très satisfait et nos clients restent :) c'est que ca doit pas être si mal.
Petit bémol cependant. K8s est un énorme changement de paradigme. Quand on a été admin sys unix pendant 25ans c'est un changement difficile. Cependant k8s en prod n'est pas une techno trop complexe. Ce n'est pas veritasfs ou oracle ou vmware :). Par contre ceph c'est piégeux, c'est vrai. Et encore avec Rook qui est l'opérateur qui gère ceph dans k8s il y a beaucoup de choses automatisées. Mais il faut quand même faire bien attention à comment sont configuré nos zones de pannes pour ne pas perdre de données en cas de problème.
Bref, k8s/ceph c'est plus simple au quotidien mais ça demande quand même certaines compétences un peu plus pointues. Et encore. J'ai eu des problèmes vraiment vicieux avec esx et encore jamais avec ceph/k8s. Il est vrai aussi que trouver des compétences sur le marché n'est pas non plus facile. Les gens qui connaissent k8s, connaissent le k8s des gafams qui ont un setup assez différent de chez noujs. C'est pour ça qu'on forme des jeunes pendant leurs études et on embauche les meilleurs à la fin.
Voilou et encore désolé pour le commentaire lapidaire, j'ai une sorte de PTSD avec les vm :)