Bonjour,
*(j'imagine que vous vouliez répondre à la liste ? :) )*
Pour le housing on n'a pas forcément besoin d'être proche, je suis à 700km de mes serveurs, si on est équipés : PDU manageables, KVM/iDrac/iLO, et en dernier recours remote-hand.
Cloud: ah bon, ce ne serait donc pas le saint graal revendiqué à grand coup de marketing ? ;)
Greg
Le 13 octobre 2013 21:50, Jérémy Martin liste@freeheberg.com a écrit :
Salut,
Location de serveurs, avec infogéreur derrière. C'est ce qu'on propose à tous nos clients, avec des serveurs pas forcément chez nous d'ailleurs.
Cloud : trop cher, io disque trop incertains.
Housing : bon marché,, mais implique d'avoir unplan de PRA ou une astreinte proche du site hébergé.
Cordialement, Jérémy Martin Directeur Technique FirstHeberg.com
Contacts téléphoniques (Lun-Ven / 9h30-12h00 - 14h00-17h30) Standard : 09 72 125 539 (tarif local) Ligne directe : 03 66 72 03 42 Mail : j.martin AT freeheberg.com Web : http://www.firstheberg.com
Le 13/10/2013 21:01, Greg a écrit :
Bonsoir,
pour les sites web a assez fort trafic, disons arbitrairement nécessitant au moins 10 serveurs, on distingue 3 types principaux d'hébergements possibles :
- à l'ancienne: infogéré en interne, avec location de baie et de BP
- typique: hébergeur mutu avec location de serveurs (OVH, Online,
Hetzner, ...)
- moderne: cloud
Chacun va défendre sa solution, ce qui m'intéresse c'est quels sont selon vous les inconvénients de l'offre d'hébergement que vous avez choisis ? (ou que vous subissez...)
Ce qui m'intéresse aussi c'est le point de vue financier de ces offres : investissement, amortissement vs. charges, etc...
D'avance je vous remercie pour vos contributions :)
Greg
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 14/10/2013 13:11, Greg a écrit :
Cloud: ah bon, ce ne serait donc pas le saint graal revendiqué à grand coup de marketing ? ;)
Je valide, le cloud c'est bien pour tester un concept une idée et démarrer la startup qui va bien. Les gros projets qui se trouvent sur le cloud et qui ont grossis vite, se retrouvent prisonnier du cloud. Quand le total de vm, données, DB pèse un poids conséquent, les sortir et orgniser une migration pour passer sur du housing coûte tellement cher en frais de projets qu'ils préfèrent payer plus cher dans le Cloud.
J'ai eu deux cas de client qui souhaitent sortir d'Amazon mais ne peuvent pas financièrement, sur un client le coût se chiffre à plus d'un million et ce n'est pas le tjm qui fait cela, non juste la bande passante facturée par Amazon pour dupliquer les serveurs (quelques milliers qui pèsent chacun assez lourd en données).
Sinon mon approche est la suivante :
- cloud pour tester, monter rapidement un environnement et pouvoir aussi tout arrêter sans surcoût - passage en vps infogéré quand l'activité augmente et que l'architecture se complexifie - ajout de dédiés haute perfs aux vps en étape intermédiaire quand les ressources sont critiques (IO pour du SQL) alors que l'applicatif n'est pas encore prêt à être réparti horzontalement et verticalement - en fonction de l'activité de l'entreprise, faire un mix entre la partie récurrente de l'activité IT (compta, dev, répo, fichiers, ...) qui est prévisible sur une année, qui ne génère pas de pic. Et une partie "on demand" gérée spécifiquement pour les pic sans pour autant payer des ressources inutiles mais cela demande que les applications soient adaptées au déploiement automatisé de ressources.
Tu peux donc avoir un mix entre housing pour le côté amortissable de l'investissement et où l'évolution est calculée et prévisible, du vps soit sur le propre housing soit sur une archi tiers en private cloud pour la partie projets, adaptabilité, gestion de pics moyens et du cloud public pour CDN, forts pics de charge (si l'appli a été développé dans ce sens sinon aucun intérêt).
Pour l'infogérance pour moi c'est à part, tu peux avoir tout cela avec tes ressources internes, tu peux tout externaliser, tu peux mixer les deux avec des périmètres définis. L'avantage pour les structures qui n'ont pas tout plein d'ingénieurs en interne, c'est plus d'astreinte, oeil externe à son infrastructure et donc conseils avisés, gestion des migrations / projets, appels d'offres neutres, ...
allé je fais ma pub pour cette partie : https://www.digdeo.fr/infogerance/serveur-dedie-vps-reseau
Le 10/14/13 6:38 AM, Wallace a écrit :
passante facturée par Amazon pour dupliquer les serveurs (quelques milliers qui pèsent chacun assez lourd en données).
Si tu peere avec amazon c'est 0 (ou alors tu parle de données dans S3 ?)
Le 15/10/2013 21:51, Aurelgadjo a écrit :
Le 10/14/13 6:38 AM, Wallace a écrit :
passante facturée par Amazon pour dupliquer les serveurs (quelques milliers qui pèsent chacun assez lourd en données).
Si tu peere avec amazon c'est 0 (ou alors tu parle de données dans S3 ?)
Amazon facture la bande passante sortante de son infra, peu importe si tu peer ou pas avec eux. A ce niveau là des projets vu les calculs Amazon on a même pas pris en compte la BP transit.
Le 10/16/13 12:52 PM, Wallace a écrit :
Le 15/10/2013 21:51, Aurelgadjo a écrit :
Le 10/14/13 6:38 AM, Wallace a écrit :
passante facturée par Amazon pour dupliquer les serveurs (quelques milliers qui pèsent chacun assez lourd en données).
Si tu peere avec amazon c'est 0 (ou alors tu parle de données dans S3 ?)
Amazon facture la bande passante sortante de son infra, peu importe si tu peer ou pas avec eux. A ce niveau là des projets vu les calculs Amazon on a même pas pris en compte la BP transit.
Exact, tu as raison ( http://aws.amazon.com/fr/directconnect/ ), c'est gratuit que dans le sens entrant
-
Aurelgadjo -
Greg -
Wallace