La Fibre
Datacenter et équipements réseaux => Datacenter => 
Énergie => Discussion démarrée par: q05 le 31 octobre 2015 à 10:28:52
-
Modération (Leon_m) : débat hors sujet déplacé, en provenance de : https://lafibre.info/datacenter/dc3-iliad/msg271890/#msg271890
A l'heure du nuage, je trouve la redondance électrique superflue. A la place, faire tourner en // l'application sur 2 DC est préférable.
On prend beaucoup trop de précautions. Un serveur qui prend feu cela n'arrive jamais, tout au plus un dégagement de fumée !
Quand à la chaleur produite, il serait bien de s'en servir pour chauffer un bâtiment.
J'ai donc un peu l'impression que l'on fait comme on l'a toujours fait sans oser repartir d'une feuiile blanche.
-
A l'heure du nuage, je trouve la redondance électrique superflue. A la place, faire tourner en // l'application sur 2 DC est préférable.
C'est ton choix, aucun problème. Tu peux très bien choisir un prestataire (très) bas de gamme avec moins de redondance. Si tu prends les serveurs bas de gamme d'OVH, par exemple, tu en auras pour ton argent. Mais ça n'est pas forcèment un bon choix. La maintenance nécessaire lors d'une panne peut couter assez cher, car ça bouffe des ressources humaines, ça prends du temps. Réparer des RAIDs cassés à cause d'une panne électrique, ça peut prendre des heures.
Mais stp, ne généralise pas. Tu parles de "cloud", mais tout le monde ne travaille pas avec des machines virtuelles, et encore moins de monde travaille avec des machines virtuelles parfaitement redondantes, avec des filers répliqués sur plusieurs sites. Ce genre d'installation coute très cher, et tout le monde ne peut pas se le permettre.
Les installations où tout est doublé sur plusieurs sites, et où la prestation continue à être assurée de manière transparente quand un site est tombé, c'est très rare.
Au final, économiquement parlant, je suis à peu près certain qu'il est plus économique, pour une installation de taille raisonnable, d'héberger ça dans un datacenter correctement redondé, avec toutes les backup nécessaires, plutôt que de tout acheter et installer en double dans plusieurs datacenters moins redondants.
Les tarifs de hosting d'Online, puisqu'on parle d'eux, sont très raisonnables par rapport à la concurrence.
On prend beaucoup trop de précautions. Un serveur qui prend feu cela n'arrive jamais, tout au plus un dégagement de fumée !
Là, forcèment, je ne peux pas être d'accord. Il n'y a pas que des serveurs dans une salle informatique. Le réseau électrique, à lui seul, peut être source d'incendie. Un mauvais contact dans une prise, dans un tableau électrique.
Leon.
-
Là, forcèment, je ne peux pas être d'accord. Il n'y a pas que des serveurs dans une salle informatique. Le réseau électrique, à lui seul, peut être source d'incendie. Un mauvais contact dans une prise, dans un tableau électrique.
Leon.
+1, voir meme +1000
Arnaud tweet régulièrement des photos d'équipements électriques qui ont cramé : disjoncteurs, boitiers de raccordement, etc. Et pourtant Online fait très attention avec des contrôles par caméra thermique et des dimensionnements adaptés aux ampérages.
-
Les installations où tout est doublé sur plusieurs sites, et où la prestation continue à être assurée de manière transparente quand un site est tombé, c'est très rare.
tiens, ça m'inspire une interrogation :
Si quelqu'un peut expliquer simplement le concept de l'anycast utilisé en failover automatique entre site, je suis partant.
Surtout les avantages/inconvénients par rapport à gérer ça avec BGP.
Quand on m'explique, ça vient de gars qui essaient de vendre des solutions, je les suspectes qu'ils ne soient pas de la plus grande objectivité.
-
C'est clair que la seule facon de faire de la haute disponibilité, c'es 2 deux site différent, je vais essayer de vous retrouver les photos du serveur qui a pris feu dans le centre de HP, les degats ca a pas été le feu, mais les pompiers qui ont tout arrosé de mousse.... et bien sur coupure generale de l'electicité dans le DC.
C'est en fait arrivé 2x, la premiere fois un server, la 2eme un UPS qui a pris feu, une capa ou l'huile c'est enflamée ca c'est resumé avec des extincteurs, ou les gardes du batiment sont intervenu rapidement, heureusment car si le systeme d'arossge automatique SPRINKLER c'était déclanché, ca aurait été 500 systemes mort en 10 secondes.
Il ya eu finalement que un bundle de 50 cables LAN cramé, qui ont du etre remplacés
-
Me rappelle la visite d'un assureur dans un petit DC :
"ah c'est bien vous avez des sprinklers
-le circuit est coupé
-mais vous etes fous ?
-non on a du FM200, parce qu'aux dernières nouvelles, l'informatique n'aime pas l'eau"
-
Ben en suisse c'est une obligation pour les assurance d'avoir un système de SPRINKLER a l'eau , dans un DC, maintenant il y a en premier le systeme de gaz de dioxide de carbone qui se délanche, ca fait aucun degats ;)
Les SPRINKLER c'est en fait une ampoule qui explose avec la chaleur, pas la fumée, c'est le 2eme remède apres le gaz qui est diffusé par detection des fumées.
(http://s8.postimg.org/b2t8davr9/spinklair.jpg)
-
amha:
azure, aws, docker,tiny server,... tout indique qu'une nouvelle façon de faire l'informatique arrive.
http://www.theregister.co.uk/2015/03/04/confirmed_tiny_windows_server_is_on_the_way/ (http://www.theregister.co.uk/2015/03/04/confirmed_tiny_windows_server_is_on_the_way/)
De ce que je comprend, il en sera bientôt fini du sysadmin qui installe SQL Server à partir d'une interface graphique sur quelques serveurs.
Il commandera une instance sur Azure et il lui restera à faire la partie spécifique à son entreprise.
Plus de patches à installer, de redondance à se préoccuper,...
Là où je travaille (proximus) on n'y est pas encore mais toutes nos applications peuvent êtres démarrées sur l'un ou l'autre DC (Bruxelles ou Mechelen).
Les filesystems sont synchronisés, les backups croisés, utilisation de load balancer F5 et j'en passe mais cela reste encore fort manuel et sujet à des erreurs de configuration. Par exemple lorsqu'un serveur doit être patché l'application doit être redémarrée. Avec le cloud l'application peut être basculée sur un autre serveur sans interruption. Pour les bases de données, on pourrait utiliser cassandra (à tolérance de panne) qui tourne en // sur plusieurs serveurs. Pour l'intégrité des filesystems, il y a maintenant par exemple lustre/zfs/Microsoft ReFS qui ne nécessitent pas de fsck après une coupure brutale. Pour la plupart des entreprises cela demanderait trop de ressources d'où le recours au cloud qui me semble inéluctable.
edit: et un des tout bon cloud : Triton https://www.joyent.com/ (https://www.joyent.com/) (avec Bryan Cantrill un des meilleurs ingénieur système au monde, ces vidéos sur yt valent le détour).
-
amha:
azure, aws, docker,tiny server,... tout indique qu'une nouvelle façon de faire l'informatique arrive.
http://www.theregister.co.uk/2015/03/04/confirmed_tiny_windows_server_is_on_the_way/ (http://www.theregister.co.uk/2015/03/04/confirmed_tiny_windows_server_is_on_the_way/)
De ce que je comprend, il en sera bientôt fini du sysadmin qui installe SQL Server à partir d'une interface graphique sur quelques serveurs.
Il commandera une instance sur Azure et il lui restera à faire la partie spécifique à son entreprise.
Plus de patches à installer, de redondance à se préoccuper,...
Là où je travaille (proximus) on n'y est pas encore mais toutes nos applications peuvent êtres démarrées sur l'un ou l'autre DC (Bruxelles ou Mechelen).
Les filesystems sont synchronisés, les backups croisés, utilisation de load balancer F5 et j'en passe mais cela reste encore fort manuel et sujet à des erreurs de configuration. Par exemple lorsqu'un serveur doit être patché l'application doit être redémarrée. Avec le cloud l'application peut être basculée sur un autre serveur sans interruption. Pour les bases de données, on pourrait utiliser cassandra (à tolérance de panne) qui tourne en // sur plusieurs serveurs.
Je crois que tu as trop lu la pub de Microsoft, sans prendre suffisamment de recul... Et surtout, tu ne parles pas du coût de la redondance de système de fichiers ou de bases de données dont tu parles. Je ne suis pas certain que ça soit facile/possible pour tous les types d'applications. Dès que tu as besoin de beaucoup d'IOPs, la réplication synchronisée coute cher.
Et les offres cloud d'Amazon/Microsoft, dont tu fais la pub, sont pour l'instant (beaucoup) plus chères que des serveurs physiques dédiés. Le rapport qualité/prix n'est pas du tout le même.
Pour moi, il est évident que les 2 approches continueront à cohabiter : des applications en direct sur des serveurs physiques classique d'un côté, et de l'autre des serveurs virtuels, ou plutôt différents niveaux de virtualisation.
Leon.
-
Effectivement, être capable de basculer sans interruption d'un site à l'autre, ce n'est pas offert à toutes les applications et cela a un coût.
Maintenant tout ce qui est vraiment critique pour une grosse entreprise est généralement réparti sur un second site avec au moins une possibilité de bascule rapide en ne perdant que le minimum de données.
Quand on a visité notre 3ème datacenter à Lyon, il y avait une sale privative qui était une sécurisation d'un autre site. Le client avait fait un cahier des charges et demandé un système de climatisation / extinction incendie différent du reste du datacenter.
-
Il faut travailler un peu en SSI les gens.
Vous verrez qu'on est très très très loin d'être prêt d'utiliser les avantages du cloud pour les serveurs même dans de grosses société multinational.
-
La SSI ne veut pas du Cloud ? Le temps que les mentalités changent, disons 5 à 10 ans. Meme l'ANSSI n'est pas contre: le Cloud permet de consolider alors que les SI privés ça fait autant d'endroits à sécuriser, de personnes à former, évangéliser, etc. Aujourd'hui on demande des normes, pas juste un nom ou une étiquette.
Quand j'ai commencé à travailler au début des années 2000, les logiciels libres c'était interdit. On voit ce qu'est devenu l'interdiction !
-
A l'heure du nuage, je trouve la redondance électrique superflue.
Parce qu'il n'y a pas de redondance électrique dans le nuage?
-
La SSI ne veut pas du Cloud ?
la SSI fait ce que le client veut. Le client voudrait de l'AS400 que les SS2I fourniraient sans même dire au client qu'il y a peut être mieux depuis 35 ans.
normalement, plus la boutique est grosse, plus ils sont conservateurs. Et puis tu fais quoi de l'équipe IT que tu as en CDI et qui administres les baies de serveurs ?
Tu les envois bosser chez Amazon ?
-
SSI=Sécurité des Systèmes d'Information :)
-
SSI=Sécurité des Systèmes d'Information :)
Oups, j'avais oublié qu'il y avait un I en plus dans le sigle (parce que je vois pas énormèment d'ingénierie dans le métier peut être)...
Je parlais bien de SS2I.
AS400, mainframe, logiciel requérant un dongle usb voir parallèle (on a un client avec un vieux serveur uniquement pour le token), etc ...
C'est pas très glorieux mais c'est l'informatique en production aujourd'hui.
-
Oups, j'avais oublié qu'il y avait un I en plus dans le sigle (parce que je vois pas énormèment d'ingénierie dans le métier peut être)...
Je parlais bien de SS2I.
AS400, mainframe, logiciel requérant un dongle usb voir parallèle (on a un client avec un vieux serveur uniquement pour le token), etc ...
C'est pas très glorieux mais c'est l'informatique en production aujourd'hui.
Dans ma boutique, il y a un soft métier, trés, trés, trés, ancien... A chaque fois que l'on appuie sur une touche du clavier, ça demande au serveur quoi faire.
C'était ridicule mais comme ça. Jusqu'au jour où le grand patron en visite à la filiale de Rio a pété un plomb : il fallait plus plusieurs secondes la bas, à chaque appuis, pour avoir la suite.
Depuis la bande de grosses nulasses qu'on a au développement (c'est comme ça que l'on appel l'ingénierie chez nous) cherchent comment accélérer la chose, personne de chez eux osant aller dire qu'il faut virer cette vieillerie.
Moralité : Tu n'as pas de couilles, va faire dev. Tu n'as vraiment pas de couilles : postules pour être leur chef.
-
Oups, j'avais oublié qu'il y avait un I en plus dans le sigle (parce que je vois pas énormèment d'ingénierie dans le métier peut être)...
Je parlais bien de SS2I.
AS400, mainframe, logiciel requérant un dongle usb voir parallèle (on a un client avec un vieux serveur uniquement pour le token), etc ...
C'est pas très glorieux mais c'est l'informatique en production aujourd'hui.
L'AS/400, c'est du virtuel depuis +5ans, IBM te le fait tourner chez eux si tu veux.
Les dongles USB ça se partage en Ethernet, on a validé un produit qui fait ça avec les jetons de licence de compilateur.
Le mainframe va disparaitre au profit de nouvelles applications.
Etc etc
On dirait que vous récitez le "too big to fail" en version "too old to change" :)
J'ai exploité la même informatique "lourde" avec par exemple des bancs de test dont l'@IP est codé en dur dans une EEPROM. Même dans mon métier, la boite se transforme petit à petit vers le cloud, ça procède pour petites touches, ou parfois ce n'est pas du cloud version publique/dédiée mais version privé. Mais ça change parce que le business gagne du fric dans ces opérations et donc OSEF que ça soit géré en local, à 10, 100 ou 1000km de là. "On s'en fout, ça marche"
-
Parce qu'il n'y a pas de redondance électrique dans le nuage?
Oui mais je me demande (c'est juste une réflexion) à quoi cela sert si l'application peut démarrer automatiquement sur un autre DC en cas de pépin. Si un fournisseur arrive à s'en passer grâce à un soft plus résistant aux pannes il sera plus compétitif. En informatique, j'ai plusieurs exemples où on se demande comment on n'y a pas pensé plus tôt: zfs ou ReFs face à la manière traditionnelle (1 disque=1 filesystem au début qui est passé petit à petit à des systèmes compliqués de raids et de LogicalVolumeManager), zones de Sun (avant c'était quasi 1 application par serveur même sur unix ce qui fait que l'on se retrouvait avec des dizaines de serveurs tournant à vide), autrefois airco de luxe coutant une fortune (maintenant on augmente la température au max et on refroidit avec l'air extérieur et une roue).
-
L'AS400 qui date d'avant le renommage en iSerie en virtuel? Je sais pas comment ils ont fait mais l'application métier ne supportent pas les version d'OS400 récente (< 10 ans).
On peut déporter les dongles mais quand tu en as un dont le driver ne se lance même pas sous Windows 2008 et qui n'est pas USB, tu fais quoi ? Tu garde un vieux 2003 physique quelque part et met un IPS devant pour éviter qu'il se fasse exploser lors des audits (et l'équipe de dev de ton IPS t'adore parce qu'a chaque audit leur analyse L7 n'est pas suffisamment fine).
Cobol sait désormais travailler avec du JSON, à ton avis pourquoi ? Parce que ces mainframes ne disparaissent pas, bien au contraire ...
On récite juste le "pourquoi dépenser pour changer quand cela marche encore".
Quoique, non, c'est plutôt 'pourquoi dépenser pour changer du !blingbling".
Les devis pour les Macbook Air passent très vite la validation et Office 365 est passé lorsque tous les monde à pris des iPhone et iPad.
Mais je vois mal Apple sortir quelque chose qui blingbling le monde de l'ERP et autre soft métier pour pouvoir renouveler l'opération.
(Non, l'iPad n'a pas réussi dans ce domaine)
Oui mais je me demande (c'est juste une réflexion) à quoi cela sert si l'application peut démarrer automatiquement sur un autre DC en cas de pépin. Si un fournisseur arrive à s'en passer grâce à un soft plus résistant aux pannes il sera plus compétitif.
Il n'y a pas de demande client donc pourquoi recoder le soft?
-
Il n'y a pas de demande client donc pourquoi recoder le soft?
Parfois juste pour le plaisir.
Où je suis il y a du gaspillage comme pas possible.
On a des applications qui ne seront plus utilisées d'ici 2 ans car les centraux téléphoniques traditionnels vont êtres démontés.
Et bien on paie quand même une fortune au fournisseur pour tout recompiler sur Itanium alors que l'application tourne depuis des années sur PA-RISC. Idem avec les serveurs: on jettre un superdome Itanium et on le remplace par quasi le même juste pour des raisons que je ne comprends pas d'opex/capex qui fait qu'un serveur de plus de 4 ans n'est plus rentable.
-
Oui mais je me demande (c'est juste une réflexion) à quoi cela sert si l'application peut démarrer automatiquement sur un autre DC en cas de pépin. Si un fournisseur arrive à s'en passer grâce à un soft plus résistant aux pannes il sera plus compétitif.
Tu es sur de toi? Dans un service informatique, as-tu une notion de la répartition du cout entre tous les postes ?
* la location du m² en salle informatique (hors prestations ci dessous)?
* la climatisation redondante/non redondante?
* la facture d'électricité, partie "non redondante"? (y compris amortissement des installations)
* la facture d'électricité, partie "redondante"? (y compris amortissement des installations)
* la facture "réseau" (interconnexion privée ou bande passante Internet)
* l'amortissement du matériel informatique?
* l'installation et la maintenance physique des serveurs?
* l'administration des serveurs?
* le développement de l'application ? (y compris mises à jour)
* l'administration de l'application?
Cette répartition est-elle la même pour tout type d'application? Clairement, non! Donc la rentabilité dont tu parles dépend énormèment du type d'application. La partie "redondance de l'alimentation" ne représente qu'une toute petite partie du cout total! Il faut bien voir que dans un grand datacenter, c'est mutualisé entre énormèment de serveurs (des dizaines de milliers), donc ça permet de baisser les couts.
Et oui, on est tous d'accord pour dire que ton approche "cloud" a des avantages dans certains cas. Mais dans d'autres, c'est moins rentable.
* Dès que tu as besoin de beaucoup d'IOPS (grosse base de donnée centrale avec énormèment de requêtes), c'est souvent plus rentable avec une plate-forme dédiée. Mettre ça dans un cloud redondé coute très cher. Surtout si tu veux de la reprise d'activité immédiate sans interruption.
* Dans beaucoup d'applications "métier" assez spécifiques, le cout d'hébergement (serveur+bâtiment+électricité+clim+réseau) est assez négligeable par rapport au cout de développement (licence logicielle ou autre) et/ou de maintenance de l'application.
* etc...
Pour finir, comme le dit PacOrly, beaucoup de plates-formes Cloud utilisent des infrastructures assez redondées, et il y a une raison. Beaucoup de plates-formes cloud sont basées sur des serveurs assez haut de gamme, avec pas mal de redondance. Mais je te l'accorde, ça n'est pas généralisé. Tout est une question de compromis. Se baser sur une infrastructure "bas de gamme", avec un taux de défaillance assez élevé, ça nécessite plus d'interventions humaines, et d'utiliser plus souvent ta "redondance logicielle", et donc d'avoir une application plus tolérante aux pannes, avec sans doutes plus de puissance informatique. Donc il faut calculer si c'est rentable, et ce calcul dépend énormèment du type d'utilisation. Une plate forme de streaming vidéo, une plate-forme e-mail, une plate-forme téléphonique, une plate-forme de grosse base de donnée, de l'hébergement web mutualisé, ça a des contraintes très très différentes!
Leon.
-
Je suis tombé sur cet article:
http://www.datacenterknowledge.com/archives/2010/07/14/data-centers-with-no-ups-or-generator/ (http://www.datacenterknowledge.com/archives/2010/07/14/data-centers-with-no-ups-or-generator/)
Je ne sais pas s'ils ont poursuivi ou pas mais en tout cas ils y pensent.
Une autre étude sur le sujet: http://research.microsoft.com/pubs/206936/ASPLOS2014.pdf (http://research.microsoft.com/pubs/206936/ASPLOS2014.pdf)
Où je suis on n'est pas encore dans le cloud (mais on en vend aux clients !), les 3 DC sont évidemment sur UPS mais en cas de perte d'1 DC (fibre coupée par exemple) nos applications redémarrent dans la minute sur l'autre DC; on utilise pour ce faire HP metro cluster ou veritas VCS.
-
Parfois juste pour le plaisir.
Où je suis il y a du gaspillage comme pas possible.
On a des applications qui ne seront plus utilisées d'ici 2 ans car les centraux téléphoniques traditionnels vont êtres démontés.
Et bien on paie quand même une fortune au fournisseur pour tout recompiler sur Itanium alors que l'application tourne depuis des années sur PA-RISC. Idem avec les serveurs: on jettre un superdome Itanium et on le remplace par quasi le même juste pour des raisons que je ne comprends pas d'opex/capex qui fait qu'un serveur de plus de 4 ans n'est plus rentable.
Je supose que tu es chez HP, sans indiscrétions.
Pour ce qui est de la tres haute disponibilité ca a été mon job pendant plus de 10 ans de conseiller aux clients des solutions multi-sites, c'est sur que c'est cher d'avoir tout a double ou a triple, mais le demarage d'un système en switchover/failover sur un autre site, ca prend 30 secondees, toujours mieux pour une banque de perdre qques transations que de perdre des milliers d'€ par minutes. ;)
Pour les superdome, c'est le cout du support qui dissuade et force a changer pour du matos plus recent, plus performent, et moins cher.
Pour faire les choses bien, tu prévoit sur chaque site un onduleur de spare et un groupe electogene en backup, pour parer aux pannes et au aux maintenance necessaire qui necessite du down time.
-
J'avais 2x Superdome: 1x PA-RISC 8800 et 1x Itanium. Le 2ème nous avait été donné, faute de débouché ! On ne s'en meme pas servi, on a remplacé les 2 par un Superdome Itanium 2 qui est resté 2-3 ans... puis qu'on a viré pour remplacement par des Integrity RX: c'est bien plus petit mais bien moins cher et tout aussi puissant.
Les RX vont rester encore un peu, pour le coup ils sont bien amortis, et les applications (du SAP, forcèment) sont migrés vers du x86 VMware & physique. C'est validé, ça tient la charge et ça coute x fois moins cher -> plus besoin de compétences spécifiques.
Je vous l'ai dit: le cloud n'est plus très loin.
L'AS400 qui date d'avant le renommage en iSerie en virtuel? Je sais pas comment ils ont fait mais l'application métier ne supportent pas les version d'OS400 récente (< 10 ans).
Hard de 2010, série Power6: l'AS/400 qui a été migré dessus était une antiquité, il a fallu des tonnes de patches pour le faire tourner (disons qu'il y avait du "retard") mais ça s'est très bien passé. Il tourne toujours ! :)
Pour AIX c'est meme combat: un client a voulu migrer d'un AIX5 sur P7 vers P8=pas supporté par les applis. Du coup IBM a sorti du P7+ et hop en virtuel aussi.
On peut déporter les dongles mais quand tu en as un dont le driver ne se lance même pas sous Windows 2008 et qui n'est pas USB, tu fais quoi ? Tu garde un vieux 2003 physique quelque part et met un IPS devant pour éviter qu'il se fasse exploser lors des audits (et l'équipe de dev de ton IPS t'adore parce qu'a chaque audit leur analyse L7 n'est pas suffisamment fine).
Lol on fait (enfin, on en prend la voie) pareil :)
-
J'ai fait un desing pour Orange, les serveurs a double c'est tres utile, mais en cas cas de gros incident dans le DC comme je l'ai expiqué , pas d'autre choix que switcher sur un autre site, le systme de facturation SIM prepayed qui fonctionne plus, c'est des pertes enorme pour eux, et ils accepte pas ca, on le comprend et ils sont pret a payer l'infra qu'il faut pour garantir un uptime de 99.9 %.
-
Je supose que tu es chez HP, sans indiscrétions.
proximus. On a plusieurs superdomes mais cela sent le sapin pour eux.
Les nouvelles applications et les DB sont maintenant sur Solaris 11 x86 ou linux.
-
J'ai fait un desing pour Orange, les serveurs a double c'est tres utile, mais en cas cas de gros incident dans le DC comme je l'ai expiqué , pas d'autre choix que switcher sur un autre site, le systme de facturation SIM prepayed qui fonctionne plus, c'est des pertes enorme pour eux, et ils accepte pas ca, on le comprend et ils sont pret a payer l'infra qu'il faut pour garantir un uptime de 99.9 %.
C'est 2 choses différentes. Avoir 2 DC pour pas être dans le noir en cas de blackout complet c'est évidemment important, mais avoir de la double alim c'est aussi important, parce que ceinture et bretelles c'est toujours mieux dans une architecture où Murphy aime s'inviter.
Entre les applicatifs qui gèrent mal le cas et les problèmes probables quand on coupe électriquement d'un coup des centaines d'équipements/serveurs...
En réalité quand tu as beaucoup de systèmes/applicatifs web tu n'as jamais envie de perdre un DC, même quand tu as la redondance sur un autre.
Après la magie des DC sync & co dans les "magic cloud" c'est bien beau mais c'est truster aveuglèment le fournisseur et n'avoir que le support pour pleurer quand ça ne fonctionne pas. Personnellement je suis bien content d'avoir le contrôle des choses et de pouvoir agir en propre en cas de problème sans dépendre d'un unique fournisseur.
-
Il faut travailler un peu en SSI les gens.
Vous verrez qu'on est très très très loin d'être prêt d'utiliser les avantages du cloud pour les serveurs même dans de grosses société multinational.
Surtout dans de grosses sociétés...
Les petites boîtes sont plus agiles pour ça ! Les grosses, il faut maintenir l'existant (ou des liens avec)...
-
Il n'y a pas de demande client donc pourquoi recoder le soft?
Parce que ça coûte cher? (respécifier, développer, tester...)
-
Après la magie des DC sync & co dans les "magic cloud" c'est bien beau mais c'est truster aveuglèment le fournisseur et n'avoir que le support pour pleurer quand ça ne fonctionne pas. Personnellement je suis bien content d'avoir le contrôle des choses et de pouvoir agir en propre en cas de problème sans dépendre d'un unique fournisseur.
Tu peux aller vers le cloud sans le faire aveuglèment, et demander un audit... Après, y a des fournisseurs qui acceptent et t'ouvrent leurs portes en grand, et d'autres qui t'envoient balader en disant : "on est certifié par xxx, voilà la certific. et c'est tout ce que vous aurez"...
-
Tu peux aller vers le cloud sans le faire aveuglèment, et demander un audit... Après, y a des fournisseurs qui acceptent et t'ouvrent leurs portes en grand, et d'autres qui t'envoient balader en disant : "on est certifié par xxx, voilà la certific. et c'est tout ce que vous aurez"...
Tu restes dépendant d'un fournisseur unique où tu es un client parmi tant d'autres.