La filiale Cloud d’Amazon a présenté, cette semaine à Las Vegas, ses plans pour atténuer son impact carbone. Ils passent par une meilleure utilisation et redistribution de l’eau consommée dans ses data centers.
La plupart des entreprises n’ont en réalité pas besoin du cloud, il serait bien plus salutaire d’optimiser les applicatifs souvent mal écrits.
Le problème est que c’est un effet de mode, et le fait d’avoir des serveurs qui se déploient automatiquement au moindre dixième de pourcent de surcharge est un cercle vicieux puisque ça oblige à avoir toujours plus de serveurs physiques qu’il faut à minima maintenir en veille même inexploités.
Serveurs physiques en pagaille qu’il faut produire, pour ensuite avoir une consommation électrique monstrueuses, une consommation d’eau monstrueuse, avec des risques au niveau sécurité car très c’est du cloud partagé. Tout ça c’est encore le modèle de la croissance illimité dans un monde fini.
Et dans le cas des AWS, Gcloud, AZURE se posent en plus des problèmes de souveraineté.
Un état quel qu’il soit ne devrait jamais héberger ses données dans une multinationale comme AWS.
Mais du coup, on parlait d’eau, non ?
Et donc l’impact du cloud au niveau écologique qui est désastreuse… Il faut savoir aller plus loin.
C’est un très grave problème qui est posé aujourd’hui au niveau mondial.
Sur le papier, je trouve cette initiative, pas mal du tout, si les agriculteurs peuvent récupérer de cette eau usée, pour l’arrosage de leurs cultures, c’est très bien.
Quelqu’un sait pourquoi on utilise de l’eau potable pour les toilettes ?
Car les installations sont mal pensé et que le filtrage et récupération des eaux grises n’est pas suffisamment répandue, accessible et mis en avant. J’y ai pensé récemment (cet été) et c’est minimum 5000€ avec l’installation pour adapter le système à ma maison… ça devrait être encourager par le gouvernement au même titre que les passoires thermiques.
Les cloud sont loin d’être indispensables, ce sont souvent que des outils de confort sans revenir au papier et au crayon, on peut très largement réduire les dépenses énergétique et d’eau, j’irai même plus loin ça à surtout été créé dans le but de satisfaire grosse multinationales et états, on vois le résultat. Qu’AWS baisse sa conso. franchement ils l’ont crée de toute pièce cette demande.
parce que tu n’étais pas né quand les plans d’urbanisation ont été fait.
Et aussi parce que pour utiliser, quand même, de l’eau impropre à la consommation, il faudrait construire un 2e réseau, dans les maisons, les rues, … Et quand on parle de 2e réseau, c’est aller et retour car il faut malgré tout recycler cette eau impropre (tu ne fais pas la vaisselle avec l’eau que tu as déjà utilisé hier n’est-ce pas ?)
Et ça implique de casser/reconstruire. Le bilan carbone il est comment ?
Ou alors tu abandonnes les villes et tu reconstruit tout ailleurs, en pensant mieux les réseaux d’eau. Oui mais tu comprends, il faut aussi construire les réseaux routiers et ferroviaires vers cet ailleurs car sinon comment vas-tu aller bosser, faire tes courses, voir le médecin ?
il n’est un secret pour personne que l’industrie du Cloud consomme aujourd’hui des milliards de litres d’eau. Inquiétant, alors que le réchauffement climatique pourrait aboutir à un déficit d’eau potable à hauteur de 50 % de la population mondiale
Avec 509 millions de km2 de la surface du globe couverte, il faut comprendre que c’est dans l’eau dite potable potentielle qu’on se sert pour la consommation de l’industrie du Cloud?
Bon on s’écarte du sujet initial…mais bon
Tu va un poil trop loin dans ton raisonnement en oubliant un gros détail, tu produits déjà chez toi de l’eau grise, et qu’il suffirait d’un second réseau chez toi et ça arrête là, pas besoin d’autres infrastructures.
Sa question est loin d’etre bête.
Bcp ont une opinion tranchée sur le cloud en mode c’est inutile
Ceci étant si on ne prends pas en compte le fait que les applications sont optimisée ou pas
Il est peut-être. plus « écologique » de centraliser la gestion des serveurs chez un prestataire (ici aws) qui fait que ça, plutot que de bricoler ça dans est coin et d’être pas 100% optimisé du point de vue énergetique
Absolument c’est un mal que trop répandu dans l’industrie informatique, en particulier le développement logiciel, depuis les marketeux ont pris en main la partie business.
C’est ce que je me dis. Quand on voit qu’un service AWS est 10x moins cher que la possession d’une machine équivalente, je me dis qu’au delà du dumping, il y a quand même pas mal de gains « écologiques »: conso inférieures, meilleur taux d’utilisation du matos, meilleur efficacité de la gestion thermique, …
Je ne sais pas si il existe des études à ce sujet.
alors il faut aller jusqu’au bout du raisonnement et quitter ce forum qui est lui même hébergé dans un centre de données …
Argument fallacieux; c’est côté Clubic que ça se passe quant à leur choix d’hébergement et d’architecture, je ne sais pas ce qu’ils font. Ça rappelle l’argumentaire des fabricants de bouteilles en plastiques comme CocaCola : « Aux gens de ne pas jeter n’importe où les bouteilles… » sauf qu’il y a déjà la responsabilité au départ de vendre de la merde (en particulier à des populations peu éduquées), qui au final se retrouve dans des décharges géantes.
Le cloud veut tout et rien dire, le principe en soit n’a rien de nouveau. Le problème vient de la commercialisation de certaines offres qui se base sur la multiplicité des serveurs (même logique pourrie avec la 5G), en particulier de le déploiement dynamiques de serveurs.
@zeebix Il suffirait déjà de récupérer les eaux de pluie sur les toitures, assez facile à faire et il n’y a pas 50km de tuyau à tirer … mais ce n’est pas le sujet ici
Tu peux faire des applications cloud « serverless » maintenant, elles sont démontées quand il y 0 traffic, et remontées que quand il y a du trafic.
Normalement, le cloud permet de réduire le nombre de machines qui tournent à ne rien faire en comparaison avec la stratégie de s’auto-héberger chacun dans son coin.
Genre mon employeur à son propre data-center qui héberge la majorité de nos applications. La nuit les serveurs tournent toujours, mais ils ne servent à rien.
Si on était hébergés dans le cloud à la place, nos VM seraient démontées le soir, et les serveurs physiques qui ont fait tourner nos applis le jours feraient tourner d’autres services à la place le soir, donc ça réduirait le nombre de machines fabriquées sans rien changer aux usages.
Par contre pour le coup d’optimiser le code, oui je peux confirmer à 100% qu’il y a des efforts immenses à faire là dessus en entreprise…
Le serverlees est du marketing, ni plus ni moins.
Le cloud ne permet pas de réduire le nombre de machines c’est totalement faux, puisque la première raison d’être du cloud c’est la très haute disponibilité du service, le partage de données, ainsi que la réduction de latence partout dans le monde.
Je reste catégorique : le premier axe d’amélioration, et de loin, c’est le code et l’optimisation système des serveurs. Le matériel est sous-exploité dans la très très large majorité des cas.
Non, la raison d’être du cloud, c’est que les giga-boites américaines qui ont des grosses variations de charge ne savaient pas quoi faire de toutes leurs machines qui sont inutiles en dehors des pics de charge (donc 95% du temps), donc ils ont cherché à les rentabiliser en louant leur capacité d’hébergement temporaire à d’autres entreprises.
Pour faire un exemple plus concret de comment ça aide à réduire le nombre de machines utilisés, voilà ce que donne le SI d’une boîte comme la mienne qui brasse plusieurs centaines de millions d’euros :
- Dans une journée habituelle, la charge est répartie de manière très inégale. Disons qu’en moyenne il faudrait 500 machines, mais pour le pic de charge de la journée c’est 1000 serveurs. Et pour les heures creuses (la nuit notamment), on pourrait être à 100 machines.
- Mais pour absorber les gros pics d’activités (genre on envoie une campagne d’emails à tous les clients et on récupère plusieurs millions de clics, suivis d’une tonnes de traitements à gérer), on est obligé de prévoir x4 en capacité, donc on a 4000 serveurs, dont 3000 qui ne servent à rien 333 jours par an, mais comme on est pas cloud, on est obligés d’acheter nos machines en avance.
- Histoire d’assurer de la redondance en cas de grosse panne, on a fait un x2 sur l’hébergement, donc on a en fait 8000 machines dont la moitié ne sert jamais parce que le datacenter principal tombe rarement en panne.
Donc on récapitule : sur une journée de travail normale, on a entre 100 et 1000 machines qui bossent réellement, et 7000 machines qui sont là « au cas où », mais qui servent souvent à rien en pratique.
Tu peux faire des optimisations de code si tu veux, tu vas peut-être réduire de 30% le nombre de machines, mais ça reste que dalle comparé au fait qu’on au 700% de sur-capacité pour gérer les imprévus. Et non, on ne peut pas se débarrasser de ces machines en trop, parce que qu’il y a un besoin immédiat d’avoir plus de serveurs, on peut pas attendre 6 mois de se faire livrer des nouvelles machines.
Si on était hébergé dans le cloud, on n’utiliserait que les 100-1000 machines dont on a réellement besoin dans la journée, au lieu de mobiliser toutes ces machines pour rien.
Et si on était hébergé dans le cloud, sur les 1000 machines qui nous servent réellement au quotidien, il y en aurait 900 qui seraient libérées pendant le soir/nuit/weekend/vacances, et qui serviraient à des services de divertissement qui eux ont plus d’activité dans ces périodes.
Ou alors pour des applications de type calcul qui s’exécutent n’importe quand et qui guettent juste les creux d’utilisation du cloud pour bénéficier de puissance pour moins cher.
Le cloud qui permet de partager des machines, c’est un peu comme avoir des équipements communs dans un grand immeuble au lieu d’avoir des équipements individuels.
Tu peux mettre 20 lave-linges en commun qui tournent tous les jours au lieu d’en avoir 100 individuels dans chaque appartement qui tournent 1 fois par semaine.
Tu peux mettre 1 imprimante commune qui remplacera facilement une centaine d’imprimantes individuelles qui impriment 1 fois tous les 3 mois.
Etc.