Bon pour crowdstrike ça n'était pas le cas mais pour les pannes cloud habituelles, c'est assez relaxant en tant que sys/cloudadmin de pouvoir mettre les mains derrière la tête et de simplement dire "on va attendre que ça revienne".
Ouais dans mon cas c'était business as usual parce qu'il n'y avait pas de machines windows dans les archis des trucs que je gérais.
L'autre avantage du cloud, c'est que comme les bonnes pratiques impose des segmentations fortes, c'est très difficile à un manager de te dire hey lâche tout pour aider les autres qui bossent sur projet tartampion, ils sont dans la panade, parce que dans toute entreprise un peu grosse ça devient tellement administrativement lourd que t'obtiens l'accès au bon compte aws/azure/google des heures voire des jours après.
En même temps si t'as une infra déjà redondée sur 2 ou 3 (suivant le type de grappes de serveurs) zones de disponibilité d'une région d'un grossiste en nuages, puis redondée ou redondable sur 1 région de plus, et qu'ensuite tu as encore besoin de pouvoir répliquer tout ça chez un autre grossiste (voire deux), c'est que tu es un peu le mouton à 5 pattes niveau rareté informatique (bonjour le coût, le besoin en compétences gigantesques, le PRA/PCA publié avec reliure cuir et broderie en 42 volumes, avec des clients requiérant une disponibilité supérieure à celle d'un grossiste en nuages donc). Ça doit exister, peut-être, mais c'est rare. En plus après faudra trouver un ou deux autres hébergeurs hors de la Terre en cas de perte de celle-ci.
Sans aller jusqu'au vrai PCA/PRA aux petits oignons, il peut être désirable d'avoir une infra transportable pour faire face à un changement de tarifs/prestations de ton nuageur.
Autrement dit : si tu es locataire, prends plutôt une petite penderie en tissu démontable et un synthétiseur qu'une armoire normande en chêne massif et un piano à queue.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Sans aller jusqu'au vrai PCA/PRA aux petits oignons, il peut être désirable d'avoir une infra transportable pour faire face à un changement de tarifs/prestations de ton nuageur.
Ça c'est indépendant, et c'est d'ailleurs pour cela que des outils comme kubernetes existent. Il y a plein de grande boites qui utilisent 2 voir 3 des grands clouds, mais pas pour une question de plan de continuité. En général c'est à cause de différentes acquisitions d'entreprises. Donc du coup il y a toujours possibilité de migrer de l'un à l'autre. Mais de toute façon ils sont tous chers et c'est tellement compliqué de calculer tes coûts avant migration que c'est difficile de savoir si tu y gagnes ou perds.
Posté par Psychofox (Mastodon) .
Évalué à 6.
Dernière modification le 07 août 2024 à 19:04.
C'est surtout qu'on n'est plus du toute dans la même psychologie qu'à l'époque ou tout le monde était dans son datacenter.
Là si ton cloud tombe, tu as toutes les chances qu'un grand nombre des tes clients et de ta compétition a aussi des problèmes. Et tu peux pointer du doigt ton fournisseur cloud comme fauteur de trouble. Du coup tout le monde est plus fataliste, tes clients comprennent et ont aussi probablement d'autres services/prestataires en rade donc la pression pour être en ligne n'existe pas autant qu'avant.
Du coup à quoi bon complexifier encore plus ton architecture, tes processus de disaster/recovery et payer plus?
Dans le monde merveilleux de l’informatique de gestion, on nous dit que l’avenir, c’est de sortir du quasi-monopole d’IBM avec z/OS pour aller dans le cloud « où que ça sera vachement mieux ».
Quand on (les « dinosaures comme moi ») demande pourquoi, — pas pour défendre IBM, mais juste pour savoir ce qu’on va y gagner — en général la réponse c’est : « le cloud c’est vachement mieux ». Par exemple, les déploiements c’est tellement simple dans le cloud. Sauf que s’il y a un point où le site central excelle, c’est dans la rapidité de déploiement !
Oui c’est plus simple dans le cloud parce que le déploiement du non z/OS est très compliqué : ça fait des décennies qu’on déploie sur site central d’un simple clic.
Le plus « drôle » dans tout ça c’est qu’en général, il est reproché au site central « sa lourdeur », et la difficulté « d’être time to market », alors qu’en fait toute cette lourdeur est lié à des processus internes complètement indépendant de la technologie…
Bref, quand on veut tuer son chien…
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
# Pratique
Posté par wilk . Évalué à 6.
On se sent moins seul quand une panne survient !
[^] # Re: Pratique
Posté par fearan . Évalué à 10.
et en plus quand le chef vient se plaindre on peut dire que chez les voisin c'est pareil \o/ !
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pratique
Posté par Psychofox (Mastodon) . Évalué à 10.
Bon pour crowdstrike ça n'était pas le cas mais pour les pannes cloud habituelles, c'est assez relaxant en tant que sys/cloudadmin de pouvoir mettre les mains derrière la tête et de simplement dire "on va attendre que ça revienne".
[^] # Re: Pratique
Posté par nigaiden . Évalué à 10.
Le XKCD qui va bien :
[^] # Re: Pratique
Posté par Psychofox (Mastodon) . Évalué à 5.
Ouais dans mon cas c'était business as usual parce qu'il n'y avait pas de machines windows dans les archis des trucs que je gérais.
L'autre avantage du cloud, c'est que comme les bonnes pratiques impose des segmentations fortes, c'est très difficile à un manager de te dire hey lâche tout pour aider les autres qui bossent sur projet tartampion, ils sont dans la panade, parce que dans toute entreprise un peu grosse ça devient tellement administrativement lourd que t'obtiens l'accès au bon compte aws/azure/google des heures voire des jours après.
[^] # Re: Pratique
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Normalement tu as un PCA/PRA multi clouds, donc au boulot !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pratique
Posté par Psychofox (Mastodon) . Évalué à 6.
Ça je l'ai vu fantasmé partout mais réalisé nul part.
[^] # Re: Pratique
Posté par wilk . Évalué à 5.
Si, le PCA/PRA c'est le fait de connaître quelqu'un qui s'y connait. Au cas où.
[^] # Re: Pratique
Posté par Benoît Sibaud (site web personnel) . Évalué à 6. Dernière modification le 07 août 2024 à 16:26.
En même temps si t'as une infra déjà redondée sur 2 ou 3 (suivant le type de grappes de serveurs) zones de disponibilité d'une région d'un grossiste en nuages, puis redondée ou redondable sur 1 région de plus, et qu'ensuite tu as encore besoin de pouvoir répliquer tout ça chez un autre grossiste (voire deux), c'est que tu es un peu le mouton à 5 pattes niveau rareté informatique (bonjour le coût, le besoin en compétences gigantesques, le PRA/PCA publié avec reliure cuir et broderie en 42 volumes, avec des clients requiérant une disponibilité supérieure à celle d'un grossiste en nuages donc). Ça doit exister, peut-être, mais c'est rare. En plus après faudra trouver un ou deux autres hébergeurs hors de la Terre en cas de perte de celle-ci.
Des cas récents de pannes : The 10 Biggest Cloud Outages Of 2024 (So Far)
[^] # Re: Pratique
Posté par devnewton 🍺 (site web personnel) . Évalué à 8. Dernière modification le 07 août 2024 à 17:54.
Sans aller jusqu'au vrai PCA/PRA aux petits oignons, il peut être désirable d'avoir une infra transportable pour faire face à un changement de tarifs/prestations de ton nuageur.
Autrement dit : si tu es locataire, prends plutôt une petite penderie en tissu démontable et un synthétiseur qu'une armoire normande en chêne massif et un piano à queue.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pratique
Posté par Psychofox (Mastodon) . Évalué à 5.
Ça c'est indépendant, et c'est d'ailleurs pour cela que des outils comme kubernetes existent. Il y a plein de grande boites qui utilisent 2 voir 3 des grands clouds, mais pas pour une question de plan de continuité. En général c'est à cause de différentes acquisitions d'entreprises. Donc du coup il y a toujours possibilité de migrer de l'un à l'autre. Mais de toute façon ils sont tous chers et c'est tellement compliqué de calculer tes coûts avant migration que c'est difficile de savoir si tu y gagnes ou perds.
[^] # Re: Pratique
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Et avec une prod bleu/verte ? La bleu chez OVH et la verte chez Scaleway par exemple ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pratique
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 07 août 2024 à 19:04.
C'est surtout qu'on n'est plus du toute dans la même psychologie qu'à l'époque ou tout le monde était dans son datacenter.
Là si ton cloud tombe, tu as toutes les chances qu'un grand nombre des tes clients et de ta compétition a aussi des problèmes. Et tu peux pointer du doigt ton fournisseur cloud comme fauteur de trouble. Du coup tout le monde est plus fataliste, tes clients comprennent et ont aussi probablement d'autres services/prestataires en rade donc la pression pour être en ligne n'existe pas autant qu'avant.
Du coup à quoi bon complexifier encore plus ton architecture, tes processus de disaster/recovery et payer plus?
[^] # Re: Pratique
Posté par Krunch (site web personnel) . Évalué à 3.
« nobody ever got fired for
buying IBMputting stuff in the cloud »pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Quelqu'un a dû se prendre les pieds dans un câble
Posté par Andre Rodier (site web personnel) . Évalué à 8.
# M’enfin !
Posté par PhRæD . Évalué à 3.
Dans le monde merveilleux de l’informatique de gestion, on nous dit que l’avenir, c’est de sortir du quasi-monopole d’IBM avec z/OS pour aller dans le cloud « où que ça sera vachement mieux ».
Quand on (les « dinosaures comme moi ») demande pourquoi, — pas pour défendre IBM, mais juste pour savoir ce qu’on va y gagner — en général la réponse c’est : « le cloud c’est vachement mieux ». Par exemple, les déploiements c’est tellement simple dans le cloud. Sauf que s’il y a un point où le site central excelle, c’est dans la rapidité de déploiement !
Oui c’est plus simple dans le cloud parce que le déploiement du non z/OS est très compliqué : ça fait des décennies qu’on déploie sur site central d’un simple clic.
Le plus « drôle » dans tout ça c’est qu’en général, il est reproché au site central « sa lourdeur », et la difficulté « d’être time to market », alors qu’en fait toute cette lourdeur est lié à des processus internes complètement indépendant de la technologie…
Bref, quand on veut tuer son chien…
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.