Reprise du message précédent :

Je conçois que c'est plus sécure, mais bon.. Le mec doit recup mon login/mdp et en plus il doit arriver à hack mon authy (ou bien me voler mon téléphone et ma tête pour unlock tout ce bordel ).
Dans mon esprit ça me semble moins probable qu'un mec qui arrive à venir chez moi pour voler ma clé tu vois. Mais je me trompe surement.

Par contre pour les autres protocoles et/ou pour les personnes non lambda, je le trouve pertinent.

C'est pas la deuxième fois que ca t'arrives ? T'en as pas marre de cliquer n'importe où ?

N'importe quoi.

Une personne lambda n'a pas la mains sur tout le système de facturation de PlamMegaCorp et les centaines de millions (de Hryvnia) brassés

 non, mais j'en ai peut-être parlé il y a quelques semaines, là je pense que je viens de comprendre le truc du colis.

Sympa la formule

Link ?

 
Yoel Roth a dû changer d'état après plusieurs menaces de mort. Et bien sûr, l'histoire de Musk était complètement inventée. Bari Weiss l'idiote utile de service.

Pas mal.

https://www.theregister.com/2023/01 [...] loud_bill/

la formule!!

Je comprends pas, qu'est-ce qui te fait dire ça ?

Ceci étant, elle n'est pas forcément facile à mettre en oeuvre parce que la difficulté est de lister les points qui sont à l'intérieur, je pense. Mais une fois qu'on l'a, elle donne un résultat exact et non pas approché.

Une certaine boîte qu'il connaît bien.

https://www.leboncoin.fr/informatique/2286641416.htm

 
R6 ?

Rainbox Six je suppose

Ah oui ça pique, surtout que c'est visiblement "highly optimized".

 
ouais, le cloud, niveau tarif, meme si c'est optimisé, ça pique toujours.
tu peux pas passer d'un modele "on prem" vers du cloud en te disant que tu va alleger ta facture, les leviers et les gains sont autres.

Ce que je trouve étonnant c'est que DHH découvre à quel point c'est le cas.

ça m'étonnes pas plus que ça ... en ce moment j'accompagne 2 boites sur une sortie du cloud et re-internalisation on prem.

Tu devrais regarder ce que fais Bari Weiss depuis quelques années, tu verras qu'il y a au moins connivence

S'il découvre, on peut aussi penser qu'il n'est pas super fiable quand il dit que c'est highly optimized  

pas faux

Après il arrive aussi à faire des cacas nerveux quand on ne lui donne pas des discounts de 80% qu'il s'était imaginé tout seul dans sa tête :
https://world.hey.com/dhh/the-only- [...] s-854e98f3
C'est peut être un peu le Christian Perronne de la tech  

Je n'en ai pas le moindre doute. Quiconque a accepté de faire cela est une sombre merde. Elle a sûrement dû retourner sa veste en catastrophe parce qu'elle subissait personnellement le contrecoup de sa saloperie.

 
Et surtout son tweet idiot sur le prix d'une grosse machine derrière
C'est comme payer des prestas, c'est trop cher pour ce que c'est mais t'achètes de la flexibilité.

 
une boite par laquelle je suis passé a fait du lift and shift, et ils ont souffert sur le cout de base de données
là ça commnce d'aller mieux après une grosse réécriture de code qui fait que les bases sql sont moins sollicités

 
mon opinion sur le sujet, après avoir construit un assez grosse app sur Azure, avoir été proche des négos pour basculer une grande entreprise de l'agroalimentaire de ses 3 datacenters vers du full cloud, et vu le coté "provider cloud qui cherche des clients"
- il faut investir dès le début dans le monitoring / controle des couts. C'est extremement facile de perdre de vue ce qui se passe, parce que la facturation est ultra granulaire, on a très vite des centaines de lignes de billing, et comprendre ce qui fait que chacune monte ou descend est ultra difficile. C'est aussi très facile d'oublier un server qui coute une blinde de l'heure tourner parce que qqn a oublié de l'éteindre.
- le benefice principale réside dans le fait d'avoir essentiellement une infra illimitée qu'on peut activer (en payant) ou désactiver quand on en a pas besoin. Ça veut dire que pour en tirer partie, les apps doivent scaler horizontalement, et avoir un très bon monitoring de leur charge pour pouvoir scale up/down si besoin. Ça veut dire aussi qu'on maitrise très bien les facteurs qui drivent la charge. De ce que j'ai vu peu de grosses boites à qui on vend monts et merveilles ont cette maturité. Et si on prend du cloud pour avoir des servers allumés 24/24 en permanent, ça rate complètement le but pour moi.
- si la charge est stable et prédictible, le cloud offre pas forcément de gain de cout vs du on prem (si on a déjà une infra qui tourne, c'est une histoire différente si on commence)
- des boites comme Stack Overflow rappellent de temps en temps qu'on peut faire un service qui scale de la mort sans avoir besoin d'un k8s et d'avoir des milliers de serveurs qui tournent
- les analytics sont surement le plus gros foutage de gueule de l'industrie : on encourage les gens "à tout garder", et ça fait qu'on voit des analystes se battrent avec des datasets énormes et des résolutions débiles (non tu n'as pas besoin des timestamps en millisecondes, la boite a un temps de réaction de l'ordre d'une demi-journée, loguer toutes les minutes diviste ton dataset par 60*1000 = 4 ordres de grandeur, et donc tes besoins en compute)

Entre le shitposting sur Twitter et les supercars j'imagine qu'il a laissé cette partie à des sous-fifres compétents quand même.

 
T'as juste de la chance mais n'en fais pas une généralité.

 
But...but....but... data is the new oil, ça serait comme jeter du pétrole par les fenêtres    

 
pour bosser sur le sujet depuis quelques années :
- tu achètes de la flexibilité/elasticité.
- time to market reduit -> one clic provisioning
- tu ne geres plus l'infra et les DC
- tu ne gagnes jamais d'argent, mais les couts son ventilés différemment.
 
mais :
- tu as intérêt a te mettre au finops dès le debut.
- il faut re-urbanniser/refactoriser faire un gros taff sur tes applis (dans l'ideal meme avant de partir ... ce qui n'est quasiment jamais le cas, il ne faut pas se mentir).
- tu es à la merci de ton provider (augmentation des couts/services dépréciés/etc ...)

Explique moi le post sur SUSE s'il avait des sous fifres compétents sur le sujet    

Totalement faux, sauf si tu continues d'utiliser oracle sans rien changer et que tu te manges un audit
 

Pas d'accord dans un contexte cogip, c'est la première grosse phobie et donc tu as des armées de théobald qui vendent des trucs comme ça et tu te retrouves avec cinq fois ta dépense cloud en consulting, à optimiser des trucs qui ne couteront jamais cher. Tu peux très bien faire des POC et de premières applis de taille raisonnable sans t'inquièter plus que ça (et en plus tu peux te les faire offrir par les fournisseurs comme ça t'es secure ). Il faut le faire quand tu sais que tu vas commencer à y aller sérieusement.
 

La deuxième grosse phobie, si tu vas chez un fournisseur sérieux les services dépréciés arrivent une fois tous les cinq ans sur des trucs mineurs, t'es prévenu 2 ans avant et généralement tu n'a pas à payer pour le service pour cette longue période à titre de "compensation".
Sur le sujet des augmentations, les hausses de prix d'Equinix, Data4, EDF and co sont déjà arrivées il y a plusieurs mois, et on ne va pas parler en public des COGIP qui ont encore leurs datacenters en propre mais la situation n'est souvent pas brillante sur le plan économique (et parfois technique/environnemental).

This. Merci de confirmer ce que j'ai toujours pensé. La volonté d'amasser des données alors/parce qu'on ne sait pas ce qu'on va en faire est d'une stupidité sans nom. 99% des données conservées ne serviront absolument à rien mais va convaincre un manager qu'il n'a pas besoin de l'amas de données inutiles en entrée...
 
Un des projets dont je suis le plus fier est le complex event processor que j'ai développé à l'époque où ce type de middleware était rare (ça l'est encore). Un CEP est un software qui fait du filtrage en entrée de flux de données. Tu crées tes filtres et tes opérations, et il les applique sur les flux au fil de l'eau. Tout ça peut se modifier en ligne, sans avoir à arrêter le système, et tu traites 100x plus de débit avec ça que si tu stockais tout dans une base de données que tu va requêter à posteriori.
 
A la fin, tu ne conserves que le résultat des opérations. Résultat, tu dégages 99% du bruit et tu ne gardes que le signal, et tu remplaces une ferme de serveurs ou un cloud par un seul PC sur un coin de bureau (j'exagère à peine). Mais ça ne fait pas techbro, et encore une fois la peur de "perdre" des données "précieuses" (elles ne le sont pas) est prédominante. Au pire, ce que tu peux faire si tu tiens VRAIMENT à savoir ce que tes clients font sur ton site de vente en ligne, c'est un échantillonnage aléatoire. Tu auras une vision suffisamment précise avec 1% des transactions, juste par la loi des grands nombres. Si au lieu d'échafauder des architectures grotesques et des stacks qui ressemblent à une machine de Goldberg, tu passes 2 jours à te demander sérieusement quels sont les KPI qui sont réellement utiles, et ça t'économisera des mois de développements et des dizaines de serveurs.

 
pas d'accord, si tu veux une vrai resilience comme ce que tu as 'on prem', sur plusieurs AZ a minima, voir plusieurs regions ... le cloud est plus cher
 

 
Oui, il faut le faire raisonnablement et pas prendre des packages chez acce**ure
 

 
agree, mais tu connais la latence des cogips
 

 
vrai

pour avoir été des 2 cotés du pitch, c'est quasiment toujours mis en avant comme un benefice. La discussion est d'ailleurs souvent "le business case de migrer dans le cloud". Et donc gueule de bois par la suite quand le business case ne se matérialise jamais. (encore une fois en contexte COGIP, une PME ayant fait du cloud depuis le premier jour aura un résultat très différent)
 

 
c'est un truc auquel il faut réfléchir, parce que effectivement si tu n'as jamais logué X et que soudain tu te rends compte que t'as besoin de X, tu peux plus revenir dans le temps et t'as pas d'historique.
1/ parfois c'est pas grave : dans 1 an tu auras ton "YTD" donc ça arrive vite. Tu peux aussi parfois recréer l'info à partir d'autres infos.
2/ plutot que de se battre sur combien d'attributs on logue, je suis largement plus partisant de se battre sur la granularité des events, et sur une historisation intelligente :  
- de millisec à sec c'est 3 ordres de grandeur, de sec à minute c'est un ordre de grandeur, de minutes à quart d'heure c'est un demi ordre de grandeur. Dans bien des cas, avoir une résolution au quart d'heure suffit (la grosse question c'est : qu'est-ce que tu comptes faire avec ce truc si ça grossit / diminue très vite ?)
3/ historisation intelligente : tu peux garder une grosse résolution sur la semaine, et historiser des aggrégations à l'heure / minutes si besoin
 
Comme tu le dis le sampling est aussi une option.
 
Là encore l'angle de vente c'est comme Dion a dit : data is the new oil, look at how cheap at TB of storage is, log first think later. Et c'est nul, c'est très casse gueule pour la suite et là encore ça contribue à la gueule de bois.

Merci de ce retour !
Je me dis que je ne suis pas à l'abri d'une bêtise de mon côté. Même si je suis "éduqué" sur le sujet, je suis sur un lan avec d'autres utilisateurs, mon pc n'est pas infaillible, ... si un .exe auquel j'accède en réseau se fait modifier et contient un keylogger ou un truc du genre, ce que je tape peut potentiellement se retrouver intercepté ou une clé privée stockée sur mon ordi être exfiltrée*.  
Ca peut aussi être un mot de passe (quand tu tapes "sudo grossecommande" ça te demande un pass en général).
J'ai l'impression que la clé hardware a quand même cet avantage d'être bloquante pour les attaques à distance, qui me semblent 1000 fois plus probables (par rapport à mon modèle de menace) qu'une attaque ciblée exactement sur ma personne avec un mec qui vient me piquer ma yubikey pendant qu'un autre détourne mon attention. On n'est pas dans un film enfin moi en tout cas c'est pas mon quotidien
 
Tiens d'ailleurs sous Windows, d'une manière générale, vous les stockez ou/comment vos clés privées ?
Il y a aussi l'éternel débat "avec ou sans mot de passe" la clé ?
Si mot de passe, est-ce que vous vous sentez plus à l'aise de mettre un mot de passe plus "faible" (voir réutilisé) dans la mesure où en théorie c'est déjà la clé en elle-même qui est la sécurité ?
... bref c'est quoi vos pratiques sur ce point ?

 
Pas si tu prends en compte le coût irréductible d'acquérir et de maintenir le savoir-faire lié à l'infrastructure. (Sans parler du coût d'opportunité lié au temps pour mettre en place cette infrastructure.)

Il suffit de calculer le vrai coût du stockage et du traitement du TB de données, et on se rend assez vite compte que ce n'est pas si cheap que ça.

Et le savoir-faire pour gérer ton cloud AWS, c'est aussi un coût irréductible. Rien que le catalogue d'AWS, savoir quoi prendre et comment faire, tout apprendre, la nomenclature, faire tes appli pour s'y adapter etc.

Faut arrêter de croire que mettre dans le Cloud ne nécessite vraiment moins de savoir-faire que d'avoir une infra sur site. C'est simplement **différent**. Les technos "on prem" évoluent aussi entre temps, c'est moins difficile de faire tourner des trucs on-prem qu'il y a 30 ans hein. Le matériel est plus fiable, plus simple, les softs d'infra mieux branlés et moins buggés, aussi plus simple d'usage, mieux outillés etc.

D'ailleurs beaucoup de technos utilisées dans le Cloud peuvent être utilisés on prem (et vice-versa)

C'est compliqué de faire des généralités vu l'absence de définition partagée, sur ce que c'est qu'une AZ par exemple (j'essaie d'avoir des discussions sérieuses et tu me mets resilience et AZ sur le même plan, à ce rythme tu vas bientôt me parler d'OVH ou des API vCloud Director ).
Ca fait "quelques" années que je fais ça et je n'ai pas encore vu un cas où cela coutait plus cher quand tu réunissais quatre conditions :
- Périmètre d'analyse raisonnable (pas de clause magique "on ne compte pas les coûts datacenters, électrique and co parce que c'est une autre direction qui paye", "on ne compte pas le projet de traitement de l'obsolescence des baie de stockage parce que ça ne m'arrange pas", "on ne compte pas la productivité des équipes parce que dans un an on sera aussi efficace que GCP", ...)
- Pas de contrat magique (vmware nous coute 100€ par an quelque soit le volume déployé et pour l'éternité et non vous ne pouvez pas voir le contrat mais écrivez quand même sur le powerpoint que vous l'avez validé)
- Pas une appli unique qui pèse plus de 100M€ de coûts CSP
- Tu ne fais pas nawak dans la migration (cad lift and shift de tous les environnements en bordel sans aucune automatisation et aucune planification, ou n'utiliser que des VM en 24/7 et du stockage bloc)