Bonjour Nal,
En ce vendredi, j'ai besoin d'évacuer l'ensemble des petits pics accumulés gratuitement à chaque nouvelle rencontre. Peut-être même qu'à la lecture de ce journal, je trouverai réconfort dans les commentaires témoignages anonymes de ceux qui comme moi, n'utilisent pas l'un des 3 services cloud mondiaux qui "scalent bien".
Le contexte
- des millions d'utilisateurs,
- des régions/zones éparpillées dans le monde
Maintenant la question qu'on nous pose :
Et vous êtes hébergés où ?
Chez OVH, en bare metal.
ah… (+tronche de la mort qui nous fait passer pour des amateurs). Mais le cloud c'est génial et ça scale bien
Après cette phrase, je n'ai déjà plus envie d'argumenter car jamais personne ne cherche à comprendre quel est le contexte qui a juste toute son importance (les moyens et les objectifs). Parce que eux ils font du cloud comme les pros de chez [remplacer par un des top50 du trafic mondial] alors celui qui n'en fait pas est au mieux un amateur, au pire un incompétent.
Et pourtant on est pas des manchots : l'infrastructure construite à partir de serveurs bare metal convient bien, les process sont automatisés. Alors peut-être qu'on va pas scaler en un clic mais on a de la marge et la mise en place de nouvelles ressources se fait très rapidement. À chacun sa solution.
Le cloud
Quand je regarde comment mettre en place des services Azure/Google/Amazon, je trouve ça d'un compliqué même pour faire des choses simples comme par exemple mettre un plafond de paiement. On finit par trouver des formations, des certifications pour ne plus voir apparaitre que des DevOps en titre de poste. C'est à dire des professionnel des templates, du clic… d'une solution américaine propriétaire.
Ils sont où les network admin, les sysadmin et les sysdba ?
Je pense qu'ils sont en voie de disparition. Le cloud, comme une boîte noire, est en train de niveler les compétences vers le bas. Ça commence maintenant dès l'école, les dév apprennent à pusher leur code directement dans le nuage et YOLO.
À moyen/long terme, n'y a t'il pas un risque dépendance totale ?
Bare Metal
Après le faux reproche du scaling, ce qui vient ensuite est le taux de disponibilité des offres non cloud. Je suis agacé de me prendre systématiquement dans les dents le coup de l'incendie d'un datacenter français… Mauvaise pub effectivement mais non représentatif de la technicité qui existe encore dans notre pays. Et puis le taux de dispo 100% n'existe pas.
Avec un peu d'huile de coude, on fait de belles choses.
Voilà, si toi aussi tu n'es pas du cloud, n'aie plus honte et assume :p
# s/vendre/jeu/ ?
Posté par moulator42 . Évalué à 3.
Trollday, c'est demain et c'est férié :)
[^] # Re: s/vendre/jeu/ ?
Posté par stopspam . Évalué à 4.
J'ai eu raison de faire ma mise en prod aujourd'hui alors :)
[^] # Re: s/vendre/jeu/ ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Une veille de week-end ou férié ?
Évidemment, t'es pas d'astreinte et t'as viaduc …après avoir eu le fun ;-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# On m'a sonné ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
Trop gros, passera pas !
# Un peu de nuance
Posté par Tangi Colin . Évalué à 5.
Tout n'est pas noir ou blanc. Je suis d'accord, on est pas obligé de faire du cloud avec multi zone. Tout dépends les objectifs et les moyens 100% d'accord.
J'ai la même soucis côté big/fast data, le nombre de projet que j'ai vu avec un système SMACK (artillerie lourde) pour un besoin finalement faible où un simple postgresql avec la sur couche timescaledb aurait largement suffit.
Quand tu as un marteau tous ressemble à un clou.
Après j'aime bien l'approche Paas/kubernetes, tu as pas besoin d'avoir des expert cyber, ou réseau ou db dans chaque projet, ils sont toujours là mais côté plate-forme et au dessus tu as besoin de moins de compétences infra et tu peux mettre plus de moyen pure métier et UX/UI. Juste d'avoir des règles claire sur les bonnes pratiques et bien définir les responsabilités entre équipe plate-forme/core et équipe projet.
# Moi je fais du cloud
Posté par Bruno (Mastodon) . Évalué à 5. Dernière modification le 10 novembre 2022 à 20:22.
mais avec OVH …
J'ai même pas brûlé
# error budget & make similar things look the same
Posté par Krunch (site web personnel) . Évalué à 10.
Voire aussi la notion de budget d'erreur. Par exemple https://sre.google/sre-book/embracing-risk/
Sinon je suis d'accord qu'il faut choisir la solution selon ses contraintes. Je ne connais pas ta situation mais j'ai aussi souvent vu le problème inverse où on prétend que les contraintes sont tellement uniques qu'il faut une solution spéciale alors que c'est assez rarement le cas au final et qu'il y a des bénéfices non négligeables à standardiser au maximum sur des solutions similaires. Voire aussi https://sre.google/sre-book/simplicity/ et https://sre.google/workbook/simplicity/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: error budget & make similar things look the same
Posté par stopspam . Évalué à 6.
Liens intéressants, je vais potasser ça.
Je suis d'accord. D'ailleurs mes besoins restent assez classique. Le choix a simplement été fait de monter notre SI sur du bare-metal au lieu du cloud.
Pour rester dans ce thème, j'ai souvent eu comme justification le fait que ça scale vite. La croyance étant que la base utilisateurs va passer de 1k à 1M en quelques heures voire jours.
Cela induit une grosse complexité dès la mise en prod que j'assimile à une optimisation beaucoup trop tôt.
[^] # Re: error budget & make similar things look the same
Posté par Misc (site web personnel) . Évalué à 4.
D'un coté, oui, ça risque pas d'arriver. De l'autre, tu es jamais à l'abri qu'Elon Musk rachète un concurrent.
Ensuite, j'ai déjà eu des soucis de performances surprise pour une CI. Le directeur a commencé à sortir git et à corriger tout les bugs remontés par coverity et à envoyer ça par batch de 20 ou 30 d'un coup, ce qui a surchargé notre gerrit et jenkins. Donc parfois les questions de passage à l'échelle sont la ou on ne s'y attends pas.
Et j'ai aussi tendance à me dire que suivant l'échelle ou tu es, la différence entre "gérer plus de traffic" et "gérer une panne due à une capacité réduite" est pas énorme.
Et pourtant, la haute dispo, c'est pour palier a des soucis plus courant que le passage à l’échelle extrême comme tu le décris.
[^] # Re: error budget & make similar things look the same
Posté par Krunch (site web personnel) . Évalué à 6.
Complétement. Mais du coup le choix cloud ou pas cloud ne change pas grand chose. Ton système ne scale pratiquement jamais que dans les dimensions que tu as prévues. Si tu as un problème de charge dans une dimension que tu n'avais pas envisagée, tu vas devoir changer ton système d'une manière ou l'autre. Le cloud peut rendre cette transition potentiellement plus rapide mais c'est pas automatiquement le cas.
Un exemple concret dans lequel j'ai été impliqué : https://cloud.google.com/blog/products/containers-kubernetes/bringing-pokemon-go-to-life-on-google-cloud
Le « seamlessly provisioned extra capacity » est une énorme simplification. Ils ont dû revoir leur architecture et, s'ils avaient été des clients lambda avec du support « normal », je suis pas sûr qu'ils s'en seraient sortis aussi bien aussi rapidement.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: error budget & make similar things look the same
Posté par stopspam . Évalué à 4.
Je l'ai vécu il y a quelques mois où un serveur et des macs dédiés aux builds android/ios ont été saturés… Chaque commit générait automatiquement une build et avec quelques dév habitués au micro-commit, on a du revoir l'intégration.
[^] # Re: error budget & make similar things look the same
Posté par Krunch (site web personnel) . Évalué à 7.
Quand tu aura fini, je t'encourage à lire les autres chapitres et le troisième livre : https://sre.google/books/ (disclaimer : j'ai contribué à Building Secure & Reliable Systems)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: error budget & make similar things look the same
Posté par Misc (site web personnel) . Évalué à 7. Dernière modification le 11 novembre 2022 à 18:20.
Est ce que ça veut dire que si je ramène le PDF la prochaine fois que je te vois au FOSDEM, tu va pouvoir le signer électroniquement ?
[^] # Re: error budget & make similar things look the same
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je rêverais de pouvoir faire cela pour certains epub (:
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: error budget & make similar things look the same
Posté par Misc (site web personnel) . Évalué à 6.
En fait, ça pourrait être un NFT /o\
[^] # Re: error budget & make similar things look the same
Posté par Krunch (site web personnel) . Évalué à 3.
Bon maintenant il faut que j'aille au FOSDEM et que je me refasse une clé OpenPGP avant.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: error budget & make similar things look the same
Posté par stopspam . Évalué à 3. Dernière modification le 13 novembre 2022 à 19:52.
+1, Belle carte de visite !
# 100% dispo
Posté par Psychofox (Mastodon) . Évalué à 10.
L'intérêt des 3 gros clouds, c'est que quand il y'a panne, la plupart de tes gros clients sont aussi en panne.
Du coup c'est jamais de ta faute. C'est juste un peu comme un jour ferié non annoncé. Pratique.
Pour le reste la scalabilité c'est bien. Mais:
1. ce n'est pas immédiat
2. si le surcoût du cloud el rend plus cher que surdimenssionner du provisionnement classique, tu n'y gagnes rien
[^] # Re: 100% dispo
Posté par stopspam . Évalué à 4.
😅🫢😁
[^] # Re: 100% dispo
Posté par windu.2b . Évalué à 1.
Un peu comme quand OVH crame un datacenter, en somme…
[^] # Re: 100% dispo
Posté par CrEv (site web personnel) . Évalué à 10.
C'était pas plutôt en Alsace ?
[^] # Re: 100% dispo
Posté par Nic0 (site web personnel) . Évalué à 3.
C'est un peu le principe du biais de vouloir se tromper à plusieurs plutôt que d'avoir raison tout seul.
# devops
Posté par Psychofox (Mastodon) . Évalué à 7. Dernière modification le 11 novembre 2022 à 02:43.
Ce qui est drôle c'est que devops est censé être une méthodologie de travail qui élimine les silos et pas un rôle.
Mais dans beaucoup de grande boites comme c'est pas toujours facile à marrier avec la séparation des privilèges tu te retrouves avec des roles devops, mais aussi des cloudops, des netops, des secops et revoilà de nouveau nos anciens silos, des tickets ouverts entre les différentes équipes, les mêmes délais de traitement qu'avant. Bon j'exagère un peu dans la réalité une fois que tu as ton VPC dispo tu fais un peu plus ce que tu veux qu'avant et tu n'as pas à attendre que tes machines soient commandées, livrées, rackées, connectéees et les ports réseaux configurés.
# Pas un soucis
Posté par Zenitram (site web personnel) . Évalué à 4.
Euh, la réponse est simple, comme pour le cloud tu as 3 serveurs bare metal sur 3 sites physiques différents (non, SBG1 et SBG2 ne sont pas 2 sites différents) et donc tu n'es pas impacté, rapide à rembarrer.
(et si pas 3 serveurs, c'est voulu de réduire le prix au risque d'indispo correspondant)
A ma connaissance les 3 "gros" n'ont jamais été HS en même temps, donc redondance de cloud et hop 100% en pratique hors tes bêtises à toi. Par contre le prix est en correspondance!
[^] # Re: Pas un soucis
Posté par stopspam . Évalué à 6.
Oui complètement. Le sujet a d'ailleurs été débunké dans tous les sens.
Dans les conversations qui sont à l'origine de mon journal, mon interlocuteur me prend de haut, maîtrise mal le sujet et n'est pas vraiment ouvert au débat, mention spéciale si c'est un pote du CEO… Je préfère laisser pisser et aller boire mon café, ailleurs.
[^] # Re: Pas un soucis
Posté par Sébastien Koechlin . Évalué à 8.
Ça me fait penser que cloud ou pas cloud; le jour ou pour une raison quelconque; ton compte est fermé (piratage, contentieux, malveillance…), si tu n'as qu'un seul fournisseur, tu l'as autant dans l'os.
# scaler sans cloud
Posté par Krunch (site web personnel) . Évalué à 4.
L'histoire de scaling du moment : https://blog.freeradical.zone/post/surviving-thriving-through-2022-11-05-meltdown/
Du coup ça me rappelle https://danga.com/words/2005_oscon/oscon-2005.pdf
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# cloud baremetal
Posté par oau . Évalué à 6.
Kubernetes sur du baremetal chez OVH c'est infiniment moins cher, non magique, avec un tarif prévisible et ça fonctionne parfaitement bien.
OVH match aussi les appels d'offres de certains secteurs économiques de plus en plus frileux à être hébergé chez les gafams.
Testé et approuvé depuis 2016 avec de plus en plus de machines.
Seul bémol la bande passante publique reste chère. Mais avec 1gbps on est quand même déjà pas mal.
Il est arrivé en 2 ans deux incidents qui ont coupé toutes ma prod pendant 2h la première fois. 15 min la seconde. Ce sont les deux seuls incidents vraiment impactant en 6ans. Problème de réseau sur le backbone qui a coupé OVH d'internet.
L'incendie de sbg n'a eut d'impact que sur les clients qui n'écoutent pas …
Installer k8s et faîtes votre cloud. Ca change la vie !
[^] # Re: cloud baremetal
Posté par Moonz . Évalué à 2.
Qu’est-ce que tu veux dire par là ?
[^] # Re: cloud baremetal
Posté par oau . Évalué à 8.
Le client qui prend toute ses machines sur sbg alors qu'on lui dit d'en prendre une sur Roubaix une sur Gravelines et une sur sbg.
[^] # Re: cloud baremetal
Posté par dyno partouzeur du centre . Évalué à 6.
Ou qui découvre qu'il aurait dû faire des backups.
[^] # Re: cloud baremetal
Posté par barmic 🦦 . Évalué à 4.
J'en suis pas convaincu. Je fais du kubernetes baremetal sur des infra à nous et je pense que tu ne compte pas le coût de maintiens à jour de kubernetes (c'est une version micro par mois, son monitoring, la mise à jour du déploiement parce que la configuration bouge avec les versions,…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: cloud baremetal
Posté par oau . Évalué à 9.
Le monitoring c'est mon métier depuis plus de 20ans et j'ai mes outils. Effectivement monitorer k8s avec les outils officiel est une plaie.
Pour les mises à jour franchement j'ai connu bien, bien pire. Websphere, oracle et même redhat c'était bien pénible. Avec le temps c'est devenu une routine de faire les maj. Et ça se passe plutôt bien.
Concernant les mises à jour des versions de l'API des ressources, kubernetes te préviens longtemps avant que ça va changer et vraiment tu as tout le temps d'anticiper. Et c'est souvent pas grand choses.
Je fais de l'administration de serveur Linux depuis la fin des années 90 et de la prod depuis le début des années 2000. On a aujourd'hui des outils qui marchent tellement bien et tellement simple d'utilisation que c'est devenu anecdotique de faire l'administration. Je pense à postgres ou à ceph par exemple. Un vrai bonheur. En plus de k8s bien sûr.
On installe tout avec l'API d'ovh puis avec des playbook ansible. Il faut moins d'une heure pour ajouter un noeud avec tout le confort moderne. Monitoring, sssd, LDAP pour k8s, conf réseau (vlan k8s, ceph, adm, monitoring, backup, vpn vive le vrack) et ajouter le nouveau noeud dans ceph. En vrai le plus long c'est d'attendre la disponibilité des serveurs et la synchronisation de ceph. Sur les grosses machines il faut des fois plusieurs mois pour les avoir.
Surtout pour le client le coût est connu à l'avance. J'ai migré des clients de chez gcp avec des factures qui pouvait varier de 50% d'un mois sur l'autre. Et chez les gafams il y a aucun support malgré les tarifs exorbitants. T'es planté ? débrouille toi.
Alors qu'est chez nous, avec le prix de la machine plus notre coût d'administration on reste moins cher d'environ 50% par rapport à gcp ou aws. On ne fait pas de azure.
Je pense sincèrement être arrivé sur un plateau qui devait tenir un moment. Je n'ai besoin de rien de plus. OVH, Debian, k8s, ceph, vrack, Kafka, gitlab, python, nuxtjs et les quelques outils de glue autour de ça et je dors très tranquillement.
[^] # Re: cloud baremetal
Posté par barmic 🦦 . Évalué à 2.
Oui donc si tu as les compétences en interne et qu'il peut prendre une parti de son temps pour ça. Voir de ce que je comprends une équipe dont c'est au moins une partie du métier et qui a l'expérience d'en répliquer un certain nombre. C'est pas ma définition de pas chère. Du coup 50% moins chère me paraît plus crédible que infiniment qui poussait à faire croire que gérer un cluster k8s ne représente pas de travail.
Au final ce que tu dis c'est qu'un votre offre de kubernetes managé est moins cher que celle des gros clouds providers. Je présume que c'est comme aller chez eux pour louer une machine, c'est pas rentable. C'est quand tu as besoin des solutions à fortes valeur ajoutée comme les faas, les api gateway, certains brokers ou des stockage objet par exemple que c'est utile.
Ils sont intéressants quand tu ne les oblige pas à t'associer du matériel à temps complet.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: cloud baremetal
Posté par oau . Évalué à 7.
Oui effectivement c'est aussi notre métier. Mais il ne faut pas croire que pour gérer ton infra, gafam ou pas, k8s ou pas, tu n'as pas besoin de compétences. La prod c'est un métier.
Ensuite oui les gafams sont intéressants quand tu ne t'en sers pas tout le temps.
Mais c'est un piège. Parce que si au début tu ne t'en sers pas tout le temps ça finira par arriver avec la croissance de ta production et c'est la que les coûts explose.
En avant vente on présente notre modèle comme un log. Plus cher au début mais dont la croissance sera un log. Là où chez un gafam c'est au mieux linéaire. Le plus souvent exponentiel. Surtout si on utilise beaucoup de leurs services à la demande.
[^] # Re: cloud baremetal
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
ceph, c'est pour les partitions modifiable de K8S ? Cela tient bien la charge ?
Est-ce que cela supporte des bases de données comme postgresql ou est-ce que vous les gérez à coté ?
"La première sécurité est la liberté"
[^] # Re: cloud baremetal
Posté par oau . Évalué à 4. Dernière modification le 13 novembre 2022 à 22:47.
Oui ceph tient très bien la charge et oui j'ai des pg et des MySQL dessus. Environ 900 pg et 150 MySQL. Par contre attention la différence de performance entre un nvme et ceph est énorme. Il faut donc bien configurer pg, ceph et bien faire attention aux requêtes que l'on fait.
Dans les cas extrêmes on peut repasser directement sur les disques locaux. Tout en gardant le tout dans k8s. On perd juste un peu de flexibilité. Les pods étant fixés sur un node particulier.
Ceph fournit aussi un fs de type S3 très utile pour le traitement de données.
Un post de fichiers dans S3 trigger une notification dans Kafka. Ensuite les données sont traités. Le gros avantage c'est que tout se fait via k8s par l'intermédiaire de knative et donc de config yaml directement dans la cicd.
[^] # Re: cloud baremetal
Posté par barmic 🦦 . Évalué à 4.
disclamer : Il ne faut vraiment pas prendre ce que je vais dire pour une remise en cause ferme. Tu connais de loin mieux se travail que moi c'est juste pour comprendre.
À quoi ça sert d'avoir du ceph sous une base de données ? La distribution des données c'est exactement le travail de la base de données (hors cas particulier comme sqlite) et ils peuvent le faire à un niveau qui semble bien plus pertinent (au lieu de devoir distribuer des open()/write()/flush()) avec plus de sémantique et la possibilité d'avoir des contraintes plus lâches (le fait de choisir son niveau d'isolation par exemple).
De ton message je comprends que c'est pratique pour du kubernetes, j'imagine parce que si tu veux migrer un nœud ou redémarrer un nœud tombé, tu sait que tu peux repartir d'un état équivalent à un redémarrage. Mais du coup ça me semble ajouter une brique présente systématiquement et qui fait du travail en plus pour économiser des ajouts/suppression de nœuds qui s'automatisent bien (surtout avec les opérateurs k8s).
Qu'est-ce que je rate ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: cloud baremetal
Posté par oau . Évalué à 2.
Tu as raison. Mais avec k8s c'est plus simple. Je ne ne gère pas l'allocation des noeuds du cluster pg sur les nodes du cluster k8s, ni la création des lv et des fs. Je n'ai pas besoin de savoir quelle instance est où ni sur quel fs etc.
Si k8s à besoin de bouger un noeud de la base sur un autre noeud du cluster k8s c'est possible. Que ce soit pour pg ou n'importe quoi d'autre d'ailleurs.
D'autres part toute la conf de pg est dans un yaml dans ma cicd. Nombre de noeud du cluster pg, user, db, config de la base, la taille des disques, le backup, le streaming des wal dans S3, le type de réplication que je veux pour chaque noeud. Je peux créer une base à partir d'une autre, à un instant t juste avec un yaml. Parfait pour tester une version de dev avec des vraies données.
Bref pour pg, comme pour tout le reste j'ai de l'infrastructure as code. En vrai techniquement ça change rien. Mais en standardisant et en automatisant à outrance on peut gérer énormément de service.
La plupart de nos clients sont des applications en SaaS ou des algorithmes de traitement de données. J'ai une stack redis, dB, front www JS et serveur d'applications backend genre python,ruby ou java. J'injecte l'id du client et le type de plateforme que je veux. Production, staging, dev, une branche en particulier etc. Et je déploy via la cicd.
Que j'ai 10 fois l'application, ou 10 000 fois ça change rien. K8s se débrouille pour tout déployer en fonction des contraintes que je lui donne. Essentiellement de ne pas démarrer deux noeuds de base pg dans la même zone.
Quand c'est des algorithmes de traitement de données je peux avoir 10 algorithmes différents qui tournent en parallèle sur les mêmes données (merci Kafka) et qui remplissent 10 cluster pg différents. Juste en me basant dans ce cas là sur le nom de la branche git. En vrai on fait l'administration pratiquement uniquement avec git. Et c'est la cicd qui gère.
Enfin quand je n'ai plus de place ou plus de ressources sur le cluster, j'ajoute des serveurs.
[^] # Re: cloud baremetal
Posté par barmic 🦦 . Évalué à 4.
De ce que je comprends la balance avoir des machines un peu spécifiques et taguer ses nœuds k8s vs gérer de manière homogène et avoir du ceph, s'explique par le volume de machines physiques (ou disons host k8s) que tu veut gérer de manière le plus homogène possible ?
Ça me semble orthogonal ou en tout cas faisable aujourd'hui avec de l'ajout/suppression de nœud. Tu dois de toute manière gérer cet ajout de nœud dans le cluster de db (et son initialisation).
Pas très rgpd-friendly ça, non ? Perso j'utilise une sorte de change data capture qui va contrôler les volumes et anonymiser.
Je comprends ça simplifie l'industrialisation à outrance, mais c'est surtout pour des cas où tu es hébergeur/cloud provider. Pour moi qui gère ma prod, ça me paraît moins pertinent. Comme on dit pour le développement "je ne suis pas google".
Merci pour les éclaircissements.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: cloud baremetal
Posté par claudex . Évalué à 4.
Je suis d'accord avec ton raisonnement, le problème, c'est qu'ajouter un nouveau noeud dans une base de donnée, ça demande souvent une grosse resynchronisation (avec potentiellement, du resharding), ce n'est pas anodin. Et avoir un noeud indisponible, c'est quand même assez fréquent (rien que pour les mises à jour). Tu risquerais d'être en permanence en train de resynchroniser ou d'accepter d'avoir des instances de la DB indisponibles régulièrement. Ce n'est pas forcément problématique, mais c'est à balancer avec la perte de performances apportée par Ceph (ou un autre système de réplication).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: cloud baremetal
Posté par barmic 🦦 . Évalué à 3.
Oui mais c'est discutable. Une resynchro depuis un nœud vierge c'est pas si lourd (la majorité du travail n'est pas de la synchro mais du streaming de données en mode bête et méchant). Pour le sharding tu n'a de resharding que si tu modifie la forme du cluster, sinon toutes les db que j'ai vu permettent le remplacement d'un nœud. Tu as le pod qui est KO, tu crée le nouveau et indique qu'il remplace le KO au reste du cluster.
C'est précisément ce que fait ceph avec un contrat bien plus rigoureux que ce que doit fournir la db.
C'est entre autre pour ça que tu fais de la réplication.
Si tu considère ton cluster ceph comme parfaitement fiable et tenir complètement la charge ça vaut presque le coup d'arrêter la réplication côté db d'ailleurs. Faut juste voir combien de connexion/requête est capable d'encaisser un nœud de db. Particulièrement si tu es en active/passive.
Je comprends c'était pour savoir s'il y avait quelque chose que je comprenais pas ou si j'avais pas les éléments à mettre en balance
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: cloud baremetal
Posté par claudex . Évalué à 3.
Mais avec une vue différente. Un pod qui est détruit est définitivement perdu. Un noeud qui reboot, est juste temporairement inaccessible et peut être récupéré, donc un rebuild n'a pas besoin d'être fait tout de suite.
Je ne comprends pas ce que tu veux dire. Si tu ne considère pas ton ceph comme fiable, le fait d'écrire une ou dix fois dessus ne me semble pas pertinent, il faudrait au moins écrire dans plusieurs clusters ceph distincts.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: cloud baremetal
Posté par barmic 🦦 . Évalué à 3.
Ce que je veux dire c'est qu'avoir :
me semble superflue. Si la couche FS est si solide (les bases de données font de la réplication pour palier au FS), alors il est intéressant de ne plus répliquer côté db ou de ne le faire plus que pour de la disponibilité (avoir le plus rapidement possible la bascule d'un serveur à un autre. C'est plus du tout la même logique et tu fais plus les même choix d'autant plus que réduire la réplication d'une couche ou de l'autre va améliorer tes performances.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: cloud baremetal
Posté par oau . Évalué à 1. Dernière modification le 15 novembre 2022 à 11:32.
la couche base de données avec N instances permet de basculer un master vers un réplica en cas de perte du master plus rapidement que de démonter un fs et le remonter ailleurs puis de relancer la base de données. Ca permet aussi de répartir les lectures sur plusieurs instances de la db
la couche ceph permet d'avoir une solidité plus importante qu'un simple fs et permet de remonter un disque d'une machine à une autre.
Donc :
si je perd un master db je bascule sur un réplica. C'est rapide, pratiquement pas de coupure
je peux répartir mes lectures sur plusieurs machine
quoi qu'il arrive je retrouve toujours mes données sur le disque tenu par ceph, modulo le temps de démonter le fs puis de le remonter ailleurs et de relancer la db.
[^] # Re: cloud baremetal
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 14 novembre 2022 à 10:37.
Est-ce que des personnes ont tenté de faire du iSCSI en raid pour faire des partitions disques pour les applications : on aurait une sorte de réplication plus rapide que du ceph, non ? (genre chaque nœud de ton cluster K8s offre des partitions iSCSI, ensuite tu montes les partitions en raid1 pour les utiliser dans tes nodes). Les applications restent mobile mais tu es en iSCSI/SAN donc plus rapide que ceph.
"La première sécurité est la liberté"
[^] # Re: cloud baremetal
Posté par oau . Évalué à 2.
c'est ce que je faisais avant avec des baies de disques. Et bien c'est un boulot à plein temps et à part entière. Sans compte le prix du hardware et l'impossibilité de vraiment savoir ce qu'il se passe dans la baie.
depuis que je fais du ceph le storage j'y pense plus.
[^] # Re: cloud baremetal
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
tu ne pourrais pas utiliser les noeuds du cluster k8s eux-même sans baie SAN spécialisé ? j'ai l'impression que vu les croisement de flux réseau, cela évite de tout concentrer vers un seul point.
"La première sécurité est la liberté"
[^] # Re: cloud baremetal
Posté par oau . Évalué à 2.
Certes mais ton disque que tu exposes en iscsi est sur une machine. Si cette machine disparait tu perds ton disque.
L'avantage de ceph est que ton disque (rbd, nfs, iscsi, samba, whatever) et toujours disponible tant que ton cluster fonctionne.
Avec le setup qu'on fait on peut perdre les deux tiers des serveurs sans perdre de données. Chaque block est répliqué trois fois.
[^] # Re: cloud baremetal
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Oui bien sur, c'est pour cela que je parlais de RAID. Tu peux faire un RAID1 de iSCSI utilisant 3 partitions.
"La première sécurité est la liberté"
[^] # Re: cloud baremetal
Posté par oau . Évalué à 1.
Pas sûr 3 DC dans 3 zones différentes. Si ta baie cramé tu perds tout.
[^] # Re: cloud baremetal
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Ce n'est pas faux.
Mais est-ce qu'en terme de latence réseau cela ne revient pas au même ?
Si tu utilises une forme d'asynchronisme sur la réplication, tu n'est pas vraiment tripliqué sur les données récentes. J'imagine que tu pourrais aussi avoir ce comportement sur du raid1 (genre réponse d'une ou 2 écritures sur 3 avant de répondre OK)
"La première sécurité est la liberté"
# Ils sont où les network admin, les sysadmin et les sysdba ?
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
Ils fabriquent les services cloud. Entre faire du monitoring, se lever la nuit parce que la dernière mise en prod a tout pété, trouver un workarround, se faire traiter de débile le matin et fournir un service de monitoring pour que le dev qui a tout pété se lève la nuit à ta place, ils ont choisi.
Cette évolution du métier vers la fourniture de service d'infrastructure est difficile a appréhender pour beaucoup d'admins mais au fond elle est très positive. Elle élimine beaucoup de zones grises qui rendaient les choses souvent pénibles. Le problème c'est qu'elle s'accompagne souvent d'une obscurité marketing et d'une inflation de moyens techniques pas forcément pertinents.
Après si les gens veulent rouler en Tesla, commander de la bouffe sur Uber et utiliser les services d'Amazon, on ne peut pas grand chose pour eux, mais jusqu'à preuve du contraire, il est encore possible de faire autrement
# Est-ce que tu sais ce que c'est le cloud ?
Posté par pasBill pasGates . Évalué à 5.
DISCLAIMER: Je bosses pour un des 3 gros clouds…
Moi je te lis, et je me dis qu'en fait, tu ne sais pas ce que c'est un cloud.
Déjà, il n'y a aucune opposition entre bare metal et cloud, tu trouves du bare metal dans ces clouds par exemple.
Quand a scaler en un clic… Déjà si tu fais du cloud correctement c'est zero click, et tu peux avoir cela même en faisant du bare metal si tu sais ce que tu fais.
Mettre un plafond de paiement oui c'est compliqué.
Quand tu as une infra entière (stockage, CPU, queues, streaming, …) et que tu arrives au chiffre maximum, tu fais quoi ? Le cloud efface tes données ? Efface toute ton infrastructure ? Coupe tes connections ?
Il faut comparer des oranges aux oranges, pas des pommes.
Et là tu confirmes qu'effectivement tu ne comprends rien à ce qu'est un cloud et ce qu'est un ingénieur cloud. Tu n'as visiblement jamais entendu parler des SDKs que n'importe quel ingénieur cloud utilise à longueur de journée et qui sont la base de toute infrastructure cloud. Personne à part les amateurs ne monte une infra cloud de production à coup de clic. Ce sont des ingénieurs qui comprennent comment construire une infra qui monte en charge et qui limite les couts, qui savent pourquoi il faut utiliser le service A plutôt que le service B selon le contexte et les besoins, qui savent comment gèrer les problèmes de latence, etc…
Non c'est surtout toi qui ne sait pas ce qu'est un cloud et qui nous la joue vieux schnock qui critique les petits jeunes et leur technologie que tu ne comprends pas.
Mais ce sont des aneries cela, tu peux faire de la haute dispo dans les deux, et tu peux faire du non haute dispo dans le deux. Typiquement les gens qui ne comprennent rien au cloud et qui ne savent même pas ce qu'est une availability zone dans AWS.
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par barmic 🦦 . Évalué à 3.
Hey pBpG ! Ça fait longtemps que je ne t'avais pas lu. Content de te revoir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Faya . Évalué à 2.
Quelqu'un demandait de ses nouvelles récemment en plus
https://linuxfr.org/users/tisaac/journaux/des-moules-et-des-sites#comment-1906135
9 mois d'absence, gros projet en gestation apparemment
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par pasBill pasGates . Évalué à 3. Dernière modification le 15 novembre 2022 à 00:30.
Ca s'appelle avoir un job ET 3 enfants en bas âge :)
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 15 novembre 2022 à 01:57.
Juste trois µ et ça scale pas papabill ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par pasBill pasGates . Évalué à 7.
Non là j'ai un gros point de contention au niveau du sommeil…
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Krunch (site web personnel) . Évalué à 3.
yaka sharder https://polysleep.org/wiki/Uberman
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par pasBill pasGates . Évalué à 3.
Perso je pensais partir en voyage d'affaire a Tahiti pendant 14 ans, le temps qu'ils grandissent, mais ma femme a refusé :)
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
C'est pas pour dire, mais elle n'a pas tort. Parce-qu'on s'en rend pas compte au début mais c'est plus tard qu'on se rend compte que petits ce sont des ennuis et plus grands ce sont de plus grands ennuis (merci grand-mère)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Micromy (site web personnel) . Évalué à 6.
(joke: on) Rhooo, c'est pas beau de s'énerver comme ça, il peut y avoir d'autres "scnock" qui lisent… (joke: off).
Je pense que Stopspam ne veut pas se payer les Clouds, mais plutôt les prétentieux / beaux parleurs / CTO sous pression du CEO / etc. qui voient dans la montée en puissance de ceux-ci un moyen de se faire mousser et de masquer leur propre incompétence derrière du buzz.
Chez nous on a eu les mêmes, avec appuis de consultants qui ont sorti, parmi les indicateurs devant nous faire choisir d'aller batifoler dans les nuages, le taux de RAM inutilisée dans nos data-center… Sans bien entendu connaître le même taux chez les fournisseurs de clouds (pourtant faut bien que les clients puissent scaler il me semble), ni se souvenir que des exigences de prod impliquent des hyperviseurs de rechange vides, ou en capacité de recevoir des VM supplémentaires en cas de panne.
Je ne vais pas dire du mal des Clouds, il y a de très bonnes choses, en particulier les api proposés qui permettent effectivement "l'infra as code" lorsque l'équipe commerciales veut un site de lancement produit qui tienne la charge, quelle qu'elle soit. Et après le lancement, on réduit la voilure et effectivement on y gagne.
Mais en entreprise il y a aussi le gestionnaire d'usine qui lui a surtout besoin de fiabilité, de latence faible pour ses automates, et de coûts budgetés précisément afin de maîtriser au mieux ses charges pour tenir son objectif sur les coûts de fabrication.
Ce n'est pas Stopspam qui ne connaît rien au(x) cloud(s), c'est plutôt ceux qui cèdent au sirènes de la puissance marketing des gros providers qui perdent parfois de vue pour quoi les Saas, Paas et autres Iaas sont faits.
Moi perso je suis pour faire de l'hybride intelligemment, en prenant le meilleur de chaque solution en fonction des besoins, des budgets et des compétences.
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Moonz . Évalué à 5.
Sans compter les discours type "vu que c’est le fournisseur cloud qui s’occupe des problématiques de fiabilité et de scalabilité, ça veut dire qu’on peut faire l’économie sur ces compétences en interne !"
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
C'est plutôt aux gens qui répondent "cloud" à l'auteur du journal qu'il faut répondre ça non ?
Ça ne change rien au fait que quand les entreprises embauchent des gens certifiés pour un "cloud" ce n'est pas pour le SDK et que les certifications que j'ai vu passer ne portent pas dessus. Même les formations azure que j'ai aperçu montrent comment cliquer sur vos sites. Pour que ton commentaire soit constructif il aurait fallu nous pointer vers vos certifications d'ingénieurs sdk etc. ;)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par pasBill pasGates . Évalué à 3.
Non, parce que visiblement lui ne comprend pas que bare metal n'est pas en opposition a cloud
Ben faut regarder à qui tu parles. Déjà içi on ne regarde pas les certifs dans les boites ou je suis passé, à l'interview on regarde si tu sais écrire du code, et si tu comprends comment un cloud fonctionne.
Normal, je bosses chez Amazon, aucune chance que les formations Azure en parlent :D
Mais plus sérieusement, c'est parce que tu ne parles visiblement pas aux bonnes personnes. Tu crois que le microservice qui utilise Azure Storage ou S3 il va utiliser des clics pour stocker des données ? Non, le microservice il est écrit en Java, il utilise l'API.
Déployer le microservice ou une update au microservice c'est idem bien évidemment.
Tu postules pour un poste de dev cloud chez les boites US, si tu leur parles de l'interface graphique ils vont te rire au nez et te renvoyer chez toi
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par cg . Évalué à 9.
D'ailleurs il est prévu de virer toutes les interfaces web chez les géants du Cloud. Par conséquent, ça s'appellera juste "Loud" (car le C signifie Clic).
Info exclusive: une source interne qui restera anonyme m'a révélé - mais ne le répétez pas - que Amazon développe une souris sans bouton (nom de code: Zero-Click Cloud Input Device™) pour les Vrais Architectes Cloud.
Plus sérieusement, un cas légitime, quand tu découvres un service, c'est de le configurer en clickodrome, récupérer le code généré, et en faire un template pour automatiser ensuite.
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Mea culpa, mais même constat pour Amazon ;D
Ceci dit, je suis d'accord avec toi sur le fait de ne pas parler aux bonnes personnes …ou pas. Chez un de mes clients, elles ont embauché une personne certifiée AWS et quand je suis allé regardé le programme il y avait plus de web que de service comme je l'espérais (code.) De plus, l'équipe en place semblait plus au fait de certaines choses, mais pour sa décharge, le nouveau profil semblait connaitre les rouages/subtilités des offres bien mieux que l'équipe de techos. On est un peu loin d'avoir l'approche des boites US en France (mais j'aime à croire que ce n'est que ma petite expérience non significative, donc pas croisé les bonnes personnes/entreprises.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par groumly . Évalué à 2.
Depuis quand les « certifications » indiquent quoi que ce soit?
Si pour toi la définition « d’ingénieur compétent dans un domaine très pointu » c’est « un mec qui a passé un exam après 3 jours de bachotage », ça explique beaucoup de choses. Si savoir gérer une infra s’apprenait en une semaine suivi d’un exam bateau, ça se saurait.
Ces certifications n’ont jamais servi qu’à rassurer des départements RH dans des industries non tech, ou des boites pourries dans le milieu tech. Et de mon expérience, les candidats qui les mettent en avant dans leur CV sont ceux que tu ne veux pas embaucher.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Je ne serai pas aussi vindicatif ou vindicative : j'en ai vu bachoter sans l'avoir… (À tout hasard, je t'invite à t'essayer aux certifs Red Hat ou encore Novell Netware à l'époque où ça existait encore.)
J'ai beaucoup de reproches à faire aux certifications depuis que Microsoft est rentré dans la danse, mais je ne cracherai pas comme toi sur le principe (qui était initialement la validation d'un savoir-faire par l'éditeur, et donc la compétence sur un produit d'après une grille précise) et me renseignerai mieux (je décerne beaucoup de préjugés et de raccourcis basés sur de fausses croyances.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par groumly . Évalué à 3.
J’ai potentiellement un peu forcit le trait. Y’a très certainement des gens très compétents qui ont une certification azure.
La ou je lâcherais pas le morceau c’est que c’est des certifs purement administrative. Une infra décente à une échelle même moyenne, c’est toujours quelque chose de très spécifique à la boite. y’aura toujours de l’exception par ci par la, une appli « legacy » (qui en fait fait tourner une partie critique du business, c’est pour ça qu’elle est legacy, personne ne veut prendre le risque de la peter), y’a les facteurs humain à prendre en compte, faut être pragmatique etc. C’est pas quelque chose qui s’apprend en brute forçant des connaissances techniques, ça s’apprend via l’experience, en ayant éteint un data center en feu (ovh, si tu nous entends!).
Le faire que des mecs certifiés ne savent que cliquer dans la console aws en dit plus sur le département HR du mec certifié que sur le cloud en tant que solution technique.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Comme l'a fait remarquer pbpg j'ai croisé un cas particulier. Et encore une fois, ces reconnaissances sont spécifiques aux produits de l'éditeur (les spécificités de la boîte sont autres choses) et se déclinent en plusieurs aspects. Je ne sais pas pour les autres niveaux mais la personne que j'ai évaluée avait passé la certif de base (fondamentaux) d'une part et les autres semblent orientées architectes https://aws.amazon.com/fr/certification/exams/?nc2=sb_ce_exm Cette personne a un certain nombre de connaissances qui la rendent apte au poste (où on ne fait pas que du aws) avec en prime, comme je l'ai mentionné, une meilleure compréhension des rouages du fournisseurs là où les autres déroulaient juste des procédures.
Je crois, pour ma part, que tout n'est ni sombre ni clair, et j'ai eu la chance d'être tombé à des endroits où les RH ne décident pas seules. (quand ça pêche en prod c'est presque toujours la validation technique —que les ressources humaines ne gèrent pas— qui a été défaillante.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Tit . Évalué à 4. Dernière modification le 18 novembre 2022 à 08:43.
tu ne sais pas si tu es un homme ou une femme ? c'est ta manière d'exprimer ta non-binarité ?
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Juste que je n'aimerais pas être taxée de tous les noms parce-qu'on interprétera que j'ai présumé que je réponds à une personne d'un sexe ou de l'autre… Pourtant nous sommes supposées et supposés savoir que nous causons peut-être à une IA ou un faux profile mais en français sexualités et genres s'invitent partout.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par groumly . Évalué à 2. Dernière modification le 18 novembre 2022 à 16:35.
Vu la tournure de phrase, j’espère que tu sais au moins si t’es un chien ou pas :)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Suis une peluche comme l'indique mon avatar.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Tit . Évalué à 4. Dernière modification le 24 novembre 2022 à 10:58.
(désolé je réponds très en retard, j'avais pas vu ta réponse)
dans la phrase "je ne serai pas aussi vindicatif [que toi]" vindicatif s'accorde en genre avec "je" pas avec le "toi" sous entendu.
par exemple "je suis aussi paresseux qu'une couleuvre" (même si couleuvre est un mot féminin).
Enfin, il me semble, si ce n'est pas le cas je serai fort surpris.
[^] # Re: Est-ce que tu sais ce que c'est le cloud ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
(pas de souci, vaut mieux tard que jamais)
Tu as entièrement raison sur le point grammatical. Et honnêtement, j'étais tellement en miroir (comme tu l'as compris accord avec l'autre en face sous-entendu) que j'avais même pas tilté : je pense pas encore assez en français… Et merci pour l'exemple qui met bien la règle en évidence.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Et pour un simple utilisateur ?
Posté par dark_moule . Évalué à 1.
Beaucoup de petites entreprises n'ont pas les compétences internes pour gérer correctement les déploiements. Et la majorité de celles avec lesquelles j'ai échangé ont un "informaticien" débordé qui n'a pas les compétences requises, mais qui permet au moins de fournir un service a minima.
Connaissez-vous des entreprises qui peuvent accompagner des petits clients pour définir leur infrastructure et prendre en charge l'exploitation ?
[^] # Re: Et pour un simple utilisateur ?
Posté par oau . Évalué à 0.
Bonjour,
c'est très exactement ce nous faisons :)
oau
[^] # Re: Et pour un simple utilisateur ?
Posté par rdg . Évalué à 3.
Curieux de savoir ou tu bosses @oau puisque tu as l'air de connaitre ton affaire!
[^] # Re: Et pour un simple utilisateur ?
Posté par oau . Évalué à 1.
hello
je n'aime pas trop faire ma pub ici, ou ailleurs d'ailleurs. On est pas particulièrement en recherche de client en ce moment. Et surtout on cherche d'abord des gens sympas avec qui bosser. Mais on peut discuter sur oau[at]nmlq.fr
[^] # Re: Et pour un simple utilisateur ?
Posté par rdg . Évalué à 1.
Conception, build & run : c'est exactement ce que nous faisons chez Enix (enix.io) :-)
[^] # Re: Et pour un simple utilisateur ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
beaucoup de SSII au forfait font cela.
"La première sécurité est la liberté"
# Cloud à la maison aussi.
Posté par Kwiknclean . Évalué à 1.
Moi aussi je suis opposé à l'idée de l'informatique en nuage, surtout pour un usage personnel du quotidien.
Déjà je trouve ça compliqué pour pas grand chose, cette manie de rebadger à leur sauce le fait de fournir de la CPU, VM, Stockage … et le moindre truc est en effet d'un compliqué …
Je ne comprends pas du tout le besoin de mettre ça chez un gros fournisseur avec que désormais pratiquement (j'ai dit pratiquement) toute la france est fibrée. Donc une board arm ou une petite machine type thinkcentre avec containers / lxd / jails fait vraiment bien le travail et permet d'avoir une infrastructure facile exportable et résiliente.
A si je triche je backup chez wasabi (c'est vraiment pas cher).
Et c'est parce que je n'ai trouvé personne qui voulait me faire de la place sur son Nas à la maison :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.