Reprise du message précédent :

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)

 
(tu as raison)
 
Réponse du sales Cloud, avec juste ce qu'il faut de trémolos dans la voix, en te fixant droit dans les yeux : oui mais Mr Muchacho, quel est le cout pour vous de ne pas prendre le bonne décision business parce que vous n'aviez pas les bonnes données ?
Partner Accenture : on a justement un service incroyable qui vous permet de transformer vos données en insights ®, qui vous permettrons justement d'augmenter votre agilité business et la rapidité de votre prise de décision (regard en coin vers le CMO), tout en maintenant un TCO en dessous de votre niveau actuel (regard en coin vers le CIO qui commençait à devenir un peu pale)
 
 
Je me rends compte que j'ai trop été dans ce genre de meetings (et en plus des 3 cotés de la discussion : vendeur, métier, IT). Ça me manque pas du tout

Sacré coïncidence.

Autant acheter une voiture en pièces détachées, de toute façon il faut savoir conduire pour en profiter

 
Faut éviter les sous-entendus avec moi, ce n'est pas très efficace, pourrais tu en venir clairement à ton idée sous-jacente ?

 
Sophisme/homme de paille. Je te demande pas d'assembler tes serveurs. Allez, tu peux mieux faire

le point en gras, se fait mais alors beaucoup beaucoup trop souvent

Tu dis qu'il y a aussi des coûts pour acquérir le savoir-faire du cloud, et tu dis qu'au final le coût est le même pour les deux solutions ("c'est pas moins, c'est différent" ). Je sous-entends laconiquement qu'il y a forcément un des deux qui est moins cher. Donc que la remarque initiale, "tu gagnes forcément de l'argent" est évidemment fausse puisqu'elle est manifestement fondée sur le fait que le cloud est plus cher au cycle d'horloge/octet de RAM, mais qu'il n'y a pas que ça qui rentre dans la balance.

Tu ne me demandes pas de construire le CPU moi même mais bien de faire l'assemblage du véhicule avec des pièces achetées un peu partout.
Et va m'upgrader un kubernetes dans plusieurs zones avec des applis en prod et quelques opérateurs sur un environnement on prem, tu me diras si c'est "juste différent"

Mais au moins ils ont économisé 100K€de consulting sur la planification de la migration  

Ah oui si tu penses que mon avis c'est celui d'une autre personne, c'est compliqué. Perso je ne pense pas que tu es forcément gagnant ou perdant, car il y a autant d'usages que de boîtes. Par contre, je suis contre le fait de dire que c'est systématiquement mieux (ou même « dans la majorité des cas »). C'est comme comparer prendre ta voiture ou l'avion. Ça dépend pourquoi. Si je veux aller chercher le pain en ville, ou aller à Bali.

Le discours dominant ça reste « le cloud c'est mieux », je crois qu'on est tous d'accord là dessus. C'est pour ça que ça fait réagir quand des gens disent publiquement l'inverse (pour leur cas d'usage). D'ailleurs, j'ai un peu horreur des gens qui vont sur Twitter pour dire « vous devez utiliser ça, c'est la base/c'est mieux/c'est connu » (genre le « si vous êtes une startup, pourquoi utiliser k8s c'est bien »).

Je pense pas pouvoir dire que le « on prem » c'est mieux dans l'absolu (mieux = plus simple, moins cher, etc.), je pense que c'est souvent très compétitif pour beaucoup de cas d'usages où l'on pense (les décideurs) que le Cloud est « mieux ». Certes, c'est pas toujours intuitif. Les profils tech pourfendeurs du « on prem » ont souvent arrêté d'en faire il y a longtemps d'ailleurs.

Sinon, on peut penser que Hey a été développé spécifiquement pour le cloud, mais qu’ils pouvaient pas prévoir toutes les charges vu que l’app était nouvelle et qu’elle a eu une croissance qui n’est pas cogipo-compatible.

C'est pourtant bien le raisonnement sous-jacent à la remarque initiale qui mentionne que le cloud est toujours plus cher. (Et accessoirement c'est exactement la comparaison qui est faite dans l'article de blog qui a suscité cette discussion.) Évidemment que c'est plus cher que le prix des pièces détachées qui sont mises dans les data centers.

Ce n'est pas ma position . Mais en même temps, DHH à le don de générer des réactions avec ses déclarations à l'arrach. Ça veut pas dire qu'il a forcément toujours tort sur l'intégralité de ce qu'il dit d'ailleurs dans l'article. Je trouve que le format « choc » va peut être aider certains à réfléchir à deux fois sur le calcul des coûts.

Et ça revient sur un truc qui m'embête beaucoup sur les RS : si tu as des propos mesurés avec plein de recul, tu fais réagir personne (et tu perds de la visibilité sur tes propos). Tout ça nous force à être clivant. L'autre avec son Tweet sur Kubernetes pour les startup à probablement maintenant une chambre d'écho énorme, alors que s'il avait eu un tweet raisonnable au départ « pourquoi k8b peut être une solution intéressante dans certains cas » (j'exagère un poil mais tu vois l'idée), personne aurait vu son tweet.

Tu veux dire qu'ils n'auraient pas pu rendre le service à leurs utilisateurs sans les capacités d'élasticité et de résilience du Cloud ? Voir même qu'ils auraient du lancer le service plus tard s'ils avaient fait le choix du on prem ?  

Bof. Regarde les propos de Jubi et Rati sur la capacité à encaisser avec peu de machines. Quand je vois l'usine à gaz pour faire des appli Cloud native, par rapport à des technos matures (voire même vieilles) qui encaissent bien, j'suis pas 100% convaincu. Dois-je rappeler aussi que les machines actuelles ce sont pas des 486DX avec le bouton Turbo actif (n'importe quel CPU x86 moderne et du NVMe)

Je pense qu'on surestime sa charge applicative, de beaucoup.

Tu n'es jamais convaincu et c'est normal tes dividendes en dépendent, ça serait la merde si tu étais convaincu que tes produits ne servaient jamais à rien    
 

C'est du marketing pour sa boite, voir plutôt sa personne, donc on a bien sûr aucune métrique d'usage, de croissance et on connait déjà la fin : DHH & JF avaient raison d'être à contre courant et après quelques soucis mineurs d'implémentation ont obtenu un résultat admirable, ils sont donc super intelligents. Magnifique leçon sur l'efficience technique par des utilisateurs de... Ruby
Prochaine étape : Macron/Mélenchon n'a pas dit une connerie, le propos a été sorti de son contexte et il a été mal compris  

4 machines en white glove service qu’on te dit !

Si j'enlève la demande de bouton turbo est ce que j'aurais le droit à un discount plus élevé ?  

C'est surtout un discours que j'ai entendu de la part des CEO et DAF qui ont peur d'avoir du CAPEX (voir c'est même un objectif annuel du DAF de n'avoir que de l'OPEX).
L'aspect vision et compétence technologique que mettra en avant le CTO ou la DSI passera souvent en second plan.
Il y a énormément de politique à ce niveau là, du même acabit que le magic quadrant..

sauf que faire tourner sa propre infra c'est finalement peu de CAPEX et beaucoup d'OPEX. Les ingés compêtants pour faire tourner l'infra coûtent plus cher que l'infra elle même

On ne répond pas à jovalise  

Tiens il neige  
Global warming my ass!  

Je ne suis pas trop d'accord avec ça.
Tu as des infras à plusieurs millions voir dizaine de millions d'euros, mais t'as pas autant en équipe ops/sysops (en sachant que qu'il y a déjà des gens en place, ça ne part pas de zéro pour ce genre de volume).

Attention je dis pas que le cloud c'est pas bien hein.

et je ne dis pas que le cloud c'est bien non plus. Je dis au contraire que l'argument du on-site "c'est beaucoup de CAPEX" totalement à côté de la réalité.  
Le HW dure facilement entre 5 ans et 10 ans de nos jours (à part peut être les batteries des onduleurs et les SSD s'ils sont utilisés dans des conditions particulières de grosses écritures, mais c'est loins d'être la norme).  
Les millions sont amortis sur cette durée. Un seul ingé va coûter >100k par an.

Ouais, 3 flocons et harko fuit chez lui.

J'ai pas dit qu'il n'y avait pas de biais cognitif.
Je dis juste que, les situations où j'ai vécu ça, ils n'étaient pas prêt à sortir de l'argent pour matériel.
L'aspect resources humaines n'était même pas discuté  

Le problème c'est que même en ayant conscience de ce phénomène, on fait aussi partie du problème, vu qu'on a ici même réagit beaucoup à ce tweet... Alors que comme tu le dis toi même, un tweet plus mesuré n'aurait jamais été relayé sur ce forum.
 
Du coup malheureusement j'ai du mal à imaginer une solution

 
Unpopular : le CAPEX c'est la vie, c'est un crédit sur 3 ans
 
Notre CFO avait réussi le tour de magie comptable de considérer que créer un site web c'était créer un asset immateriel, donc on avait réussi à CAPEXer les dépenses du projet. On CAPEXait tout, y compris les expenses, donc on a capexé des pizzas.  
 
C'est d'ailleurs un problème quand tu passes sur du SaaS, c'est que tout d'un coup toutes tes dépenses deviennent de l'OPEX, et la première année ça pique si le CFO est un peu rigide
 
Note : tout ceci est débile, puisque la vraie métrique devrait etre le cout annualisé, mais dans les COGIP c'est un sport national de trouver des façons créatives de taper dans du budget ailleurs parce que t'en a plus. C'est le plus proche que les CFOs ont de la notion de trait / interface : is it marketing related ? OK so we can expense it on marketing expenditure. Does it create an asset ? It can be CAPEXed.
 
Du coup on était arrivés en mode eCommerce implements MarketingRelated, Asset, et on bouffait à tous les rateliers

2016:

Petit problème: c'était complètement bidon.
 

non, mais je vous propose de vous upgrader pour le plan écolo, 0.01% de votre électricité viendra d'une éolienne au lieu de 100% charbon

Soit tu as un biais dans ton dataset, peut être que n'as travaillé que pour google cloud, aws et azure, soit tu es sérieusement à côté du sujet
Je serais curieux de voir à combien de CEO tu as parlé ou combien de CFO t'ont confirmé qu'ils avaient un objectif annuel de 0 CAPEX  (et combien de grilles d'évaluation Gartner tu as rempli). Sur le split capex/opex je pense que tu ne te rends pas bien compte mais même chez un fournisseur cloud c'est souvent faux, même à 25% de croissance annuelle

Comme 97,5% du cac40 dès que le projet coûte un peu d'argent
(il y en a une qui ne le fait pas systématiquement parce que les investisseurs suivent le niveau élevé de capex de la boite)
 
 

 
Aucune idée, on va l'attendre au tournant j'imagine. Tu penses que c'est qu'une PR stunt au final ?
 

 
Oui…  
 

 
C'est tout à fait normal que la création de tes devs ait une valorisation comptable. Le comptable fait souvent le parallèle avec un loueur de voitures, il doit bien amortir ses voitures qu'il a acheté. Elles ont une valeur.

oui, mais les vendeurs de hw font tous pour que tu renouvelles au bout de 3 ans ... 5 ans grand max.

Ca dépend du sens profond de ta question, je pense qu'ils vont bien enlever des trucs d'AWS pour les mettre ailleurs. Est ce que cela leur apportera vraiment des bénéfices en tant qu'entreprise ? On n'aura jamais le fin mot de l'histoire et il n'aura aucune raison de le donner, particulièrement si cela montre qu'ils ne sont pas aussi doués et visionnaires que cela
Et en plus ça ne donnerait pas du bon story telling
Seule exception : un immense carton en prod où il sera obligé de manger son chapeau mais je ne lui souhaite pas
 
On a quand même l'impression qu'au delà de hey ils ont foutu la majorité de leur échecs commerciaux et app legacy sur aws, ce qui est assez curieux et ressemble à la migration lift and shift débile dont on parlait  

Je découvre le changement de licence OGL 1.0 -> OGL 1.1 (licence de jeu de rôles) qui a eu lieu récemment, je vous laisse chercher sur Google vous allez apprécier la chose

C'est quand même chaud de réussir à doubler Games Workshop en termes de rapacité quand même.

Laugh in Nintendo

Tirs tirés
(sauce)