OVH Cloud OVH Cloud

Baie OVH

72 réponses
Avatar
SK Lurk
Bonjour,
Quelqu'un sait-il si dans l'offre 1 baie + 100 Mbits/s pour 810 euros, il
s'agit de 100 Mbits/s dédié ? Sinon, quel est le minimum garanti ? (le
service commercial d'OVH n'est pas clair à ce sujet).
Merci

10 réponses

Avatar
Issam Hakimi
avait soumis l'idée :
Vous melangez 2 thermes: mutualiser les resources et mutualiser
les couts. ça n'a rien à avoir.

Oula Octave qui va me donner un cours de gestion/finance/marketo


Chez Ovh, on mutualise bien les couts et, là je me repete
un peu, on fait profiter le client de cette mutualisation.
C'est à dire qu'avec le nombre des clients qu'on a et ce
qu'ils nous utilisent réellement, ça serait une arnaque de
les facturer ce qu'ils _peuvent_ utiliser.


Déjà ce n'est pas ce qu'ils _peuvent_ utiliser mais ce qu'il vous
*achete contractuellement*.
Si un client vous achete 10Mbps vous lui facturer bien 10mbps mais pas
sa consommation réel (qui est dans cette exemple de 5mbps) ...

Par contre de votre coté pour bénéficier de coût bas, vous effectuer
d'une part ce qu'on apelle (en aware) le dumping.
Je m'explique :

3 clients vous achetes 10Mbps donc une conso global "comptable" de
30Mbps
Hors en pratique, la conso moyenne de ces 3 clients est de 15Mbps

A partir de cas, il y a deux (en gros) choix de politique :
CHOIX 1 : Je provisionne (sur mon infra, etc..) et rachete la totalité
de la consommation "comptable" à mes fournisseurs.

CHOIX 2 : je me base sur la consommation pratique et provisionne,
rachete en conséquence (avec + ou - une marge de tolérance)

DANS les deux cas, il y a une mutualisation de coût (ET OUI!!) qui
permet d'obtenir de meilleurs tarifs (achat de gros..).

Si je me trouve dans le choix 1, je peux affirmer que mes clients
disposent d'une connexion dédié et garantie, puisque je m'engage
contractuellement avec mes fournisseurs de mon coté.
Ainsi j'evite le risque qu'un de mes fournisseurs ne veuille plus me
fournir de Mbps supplémentaire pour une raison X.

Dans le deuxième choix, je prend un risque qui est de me retrouver à
cours de Mbps à un instant T pour differentes raisons.Et donc dans ce
cas, je ne peux garantir à mes clients un connexion non mutualisé et
garantie.
Et oui car contractuellement, vous garantissez la connexion comptable
et non pratique.

Ces choix correspondent à des politiques/orientations/clientèles
différentes ET surtout un gestion de risques :)

Le reste de votre message ce passe de commentaire ...
Et surtout réaffirme bien ce que nous disions plus haut, la connexion
est mutualisé sur tous les clients OVH et non le contraire comme vous
l'avez affirmé.

Pour conclure dans le cours caricaturé que vous avez essayé de me
donner :
-> 3 clients loue 3 telecommandes à OVH, au lieu de les achéter chacun
de son coté directement au fabricant
= mutualisation de coûts.

-> Ovh achete une télécommande et loue 3 télécommandes à 3 clients :
* client A : lundi, mardi
* client B : mercredi, jeudi
* client C : jeudi, vendredi
en prenant le risque que les 3 clients demandent en même temps cette
télécommande le samedi,dimanche
= Gestion de risques, ~dumping, ~folie(question de point de vue)

Cordialement,
Issam Hakimi

Avatar
Spyou
Exactement, comment dans ce cas peut on raisonnablement acheter 100 Mb/s
pour au final vendre 200 Mb/s ? Même si en "pratique" tes clients ne
consomment que x% du trafic acheté, que se passe t'il s'ils décident
*ensemble* de consommer ce qu'ils ont acheté ? Moi je n'appelle pas cela de
la mutualisation de cout, mais de la gestion de risque, ce qui est bien
différent.


Et encore, il faut a mon sens differencier 3 et non 2 cas :

- Celui du réseau dimentionné a conso global + X%, modele low cost
- Celui du réseau dimentionné a commit vendu + X%, mais qui achete son
transit pil poil a conso global, modele moyen
- Celui du réseau dimentionné a commit vendu x 2 et qui achete 100% de
ce qui a été vendu


Ce sont 3 conceptions differentes de la gestion de risque :)

Avatar
Mento
Oula Octave qui va me donner un cours de gestion/finance/marketo


On va plutot comparer le bilan de vos 2 societes.

Avatar
Calimero
Issam Hakimi wrote:
-> Ovh achete une télécommande et loue 3 télécommandes à 3 clients :
* client A : lundi, mardi
* client B : mercredi, jeudi
* client C : jeudi, vendredi
en prenant le risque que les 3 clients demandent en même temps cette
télécommande le samedi,dimanche
= Gestion de risques, ~dumping, ~folie(question de point de vue)


En meme temps, c'est un peu pareil dans tous les secteurs, donc
pourquoi l'hébergement y dérogerait ?

--
@+
Calimero

Avatar
FightClub!
wrote:

Mutualisé les resources ? On ne peut pas le faire. Il faut assurer
une qualité de service parceque les clients n'achete pas 100Mbps
pour utiliser que 10Mbps.


Exactement, comment dans ce cas peut on raisonnablement acheter 100 Mb/s
pour au final vendre 200 Mb/s ? Même si en "pratique" tes clients ne


En achetant 100Mb/s de bande passante et en revendant 200Mb/s de
transit, ça me parait faisable, non ?

consomment que x% du trafic acheté, que se passe t'il s'ils décident
*ensemble* de consommer ce qu'ils ont acheté ? Moi je n'appelle pas cela de
la mutualisation de cout, mais de la gestion de risque, ce qui est bien
différent.


A un moment ou a un autre il faut bien que quelqu'un le prenne, ce
risque, sinon il faudrait des liens de plusieurs centaines de Go entre
chaque pop, qui ferait transiter chacun quelques Mb/s seulement. Quel
est l'interêt ? L'utilisateur paierait X fois plus cher pour le même
service rendu.
Le cas ou tout le monde veut 100% de son transit en même temps est très
peu probable, à partir de certain volume il est même *infiniment* peu
probable. Et heureusement que certains l'ont compris : par exemple en
assurance combien on paierait si l'assureur commençait à prévoir le cas
où toutes les voitures du parc automobile français ont un accident en
même temps ?!
Je n'ai qu'une vague idée du nombre de sites Internet en France, mais il
est fort à parier qu'au niveau des chiffres on se trouve dans des
ratios équivalent de ceux de mon exemple avec les voitures.



Puis ça ne coute rien de mutualiser les
resources. Comme vous, Ovh achete du transit et paie à 95% de
l'utilisation réel et pas à la taille de la connexion que vous avez
chez vos fournisseurs de transit.


C'est le cas pour ovh certes, mais pas le notre : nous achetons 100% de ce
que nous vendons en commit chez nos fournisseurs, afin d'avoir une garantie
contractuelle de provisionnement du transit sur les liens en question.


Entre vous et votre opérateur oui, sur combien de mètres de long c'est
valable ? Et quand bien même ce soit en kilomètres, entre votre
fournisseur et les utilisateurs qui sont à l'autre extrémité ça se passe
comment ?


Encore une fois, nous ne vendons pas le même produit, lorsqu'un client signe
100 Mb/s, nous nous engageons contractuellement à acheter *au moins* 100
Mb/s sur nos transitaires.


Pour moi ça déplace le risque (et les mutualisations de coûts associés)
vers vos fournisseurs, rien de plus.


Ce n'est pas un problème commercial : comme dans les produits de
consommation, il existe des gammes de produit pour tout le monde. On peut
acheter du nutella, ou une parte à tartiner sans nom, ce n'en fait pas
forcemment du Nutella. De même que lorsque l'on achete un téléviseur 16/9
70 cm, le prix peut varier du simple au triple, en fonction des composants,
des garanties apportées, intervention sur site, etc...


Oui mais la on change de sujet, on parlait de quantité et dans ces deux
exemples il est question de qualité et/ou de service associés, ce qui
n'a rien à voir.
Pour en revenir au sujet initial, il est évident qu'un kilo de pâte a
tartiner X ou un kilo de pâte à tartiner Y ça fait le même poids, et
donc si par exemple on le mets dans un camion, ça revient *strictement*
au même.
Pour le transit c'est pareil, du moment que le client a le transit dont
il a besoin, il n'y a aucune différence entre acheter ce transit au
volume réel ou bien en acheter au volume hypothétique : les octets de
données qui passent iront à la même vitesse (et bien souvent sur les
mêmes tuyaux !)


Vendre de la bande passante (largeur d'un tuyau) et du transit internet
(trafic circulant réellement sur Internet) sont 2 choses bien différentes,
et beaucoup d'acteurs font (intentionnellement ou non) l'amalgame entre les
2, c'est regrettable, car celui qui paye les pots cassés, c'est toujours le
client.



Donc CQFD : le client paye forcément plus (d'euros ou de pots cassés
c'est pareil) quand il achète un tuyau à largeur fixe, puisqu'il est
obligé de le prévoir pour sa consommation maximale. L'amalgame en
question ne sert évidemment de justification qu'à ceux qui vendent du
tuyau, puisque ceux qui vendent du transit réel sont moins cher pour un
service équivalent (il n'ont donc rien à justifier).

--

http://www.SD2i.com
_ Cabinet SD2i _


Avatar
Spyou
Pour moi ça déplace le risque (et les mutualisations de coûts associés)
vers vos fournisseurs, rien de plus.


Tout a fait .. mais c'est a celui qui accepte de prendre le risque de le
gerer, ca a toujours été comme ca depuis que le monde est monde .. il
y'en a dont le metier n'est pas de gerer ce risque la, point :)

Avatar
Spyou
Oula Octave qui va me donner un cours de gestion/finance/marketo



On va plutot comparer le bilan de vos 2 societes.


Pour ca, il faudrai deja qu'OVH publie les 6 bilans en retard qu'ils ont :)


Avatar
Spyou
En meme temps, c'est un peu pareil dans tous les secteurs, donc pourquoi
l'hébergement y dérogerait ?


C'est pareil dans tous les secteurs .. il y'a des restaurant qui disent
en permanence "vennez y aura de la place" au téléphone et sur place on
poireaute X temps pour avoir de la place .. et il y'a ceux qui disent
"ah non désolé il y'aura pas de place avant 23h" et ou on s'assoie tout
de suite quand on arrive :)

Avatar
Calimero
Spyou wrote:

En meme temps, c'est un peu pareil dans tous les secteurs, donc
pourquoi l'hébergement y dérogerait ?



C'est pareil dans tous les secteurs .. il y'a des restaurant qui disent
en permanence "vennez y aura de la place" au téléphone et sur place on
poireaute X temps pour avoir de la place .. et il y'a ceux qui disent
"ah non désolé il y'aura pas de place avant 23h" et ou on s'assoie tout
de suite quand on arrive :)


Oui. Je ne préjugeais pas de la qualité de telle ou telle politique,
je disais que c'était pas une idée neuve le surbooking.
C'est une question d'étude actuarielle ;)

Dans certains secteurs, un gestionnaire qui provisionnerait 1:1
passerait pour un con.

--
@+
Calimero


Avatar
Christophe Casalegno
FightClub! wrote:

En achetant 100Mb/s de bande passante et en revendant 200Mb/s de
transit, ça me parait faisable, non ?


?

Le cas ou tout le monde veut 100% de son transit en même temps est très
peu probable, à partir de certain volume il est même *infiniment* peu
probable. Et heureusement que certains l'ont compris : par exemple en
assurance combien on paierait si l'assureur commençait à prévoir le cas
où toutes les voitures du parc automobile français ont un accident en
même temps ?!


Une assurance fait de la gestion de risque, pas de l'achat/revente de
service.

Entre vous et votre opérateur oui, sur combien de mètres de long c'est
valable ? Et quand bien même ce soit en kilomètres, entre votre
fournisseur et les utilisateurs qui sont à l'autre extrémité ça se passe
comment ?


D'ou l'intérêt également du nombre d'opérateur. L'opérateur vous garanti
lui, le provisionnement de cet achat sur l'intégralité de son réseau, la
notion de risque, sur celui qui vends derriere du transit multi-op est
nulle, le risque est géré par le "propriétaire" du réseau, qui fournit la
matière première : contractuellement, cet achat est provisionné, il n'y a
donc pas de problèmes.

Pour moi ça déplace le risque (et les mutualisations de coûts associés)
vers vos fournisseurs, rien de plus.


C'est une différence de taille :

1) Il n'y a justement pas à gérer ce risque.
2) Contractuellement, ce risque est inexistant vu que nous demandons
contractuellement la garantie du provisionnement sur le réseau dudit
opérateur. C'est à lui, fournisseur de la "matière première" de
dimensionner/redimensionner son réseau en conséquence.

Oui mais la on change de sujet, on parlait de quantité et dans ces deux
exemples il est question de qualité et/ou de service associés, ce qui
n'a rien à voir.


Bien au contraire, car on parle de quantité, mais pas de la même chose. 100
Mb/s de BP n'est pas 100 Mb/s de transit, tout comme une canalisation d'une
capacité de 1000L/minute, n'est pas un volume d'eau de 1000L/minute (qui
peut n'etre que de 10L...

Pour le transit c'est pareil, du moment que le client a le transit dont
il a besoin, il n'y a aucune différence entre acheter ce transit au
volume réel ou bien en acheter au volume hypothétique : les octets de
données qui passent iront à la même vitesse (et bien souvent sur les
mêmes tuyaux !)


Mais justement : le risque qu'il ne puisse pas avoir ce transit augmente de
manière considérable dans l'un des cas. D'ailleurs, il n'y a qu'à voir
lorsqu'un point de peering se casse la gueule, les débits de certains
fournisseurs vers certains réseaux/fai, devient ridicule : il n'y a pas le
transit nécessaire.

question ne sert évidemment de justification qu'à ceux qui vendent du
tuyau, puisque ceux qui vendent du transit réel sont moins cher pour un
service équivalent (il n'ont donc rien à justifier).


C'est tout le contraire : vendre de la BP ne coute rien, puisque
contractuellement, il s'agit le plus souvent de la largeur d'un tuyau chez
l'hébergeur uniquement. Dans l'absolu je veux donc vendre 1 Gb/s de BP pour
25 euro /mois et ne dimmensionner les liens de transit sortant que de 100
Mb/s. Il n'y a pas mensonge, mais c'est bel et bien de la tromperie pour le
client.

Le transit est donc plus cher que de la BP (qui ne coute rien sinon le
dimmensionnement des cables et ports et équipements). Le transit lui, se
provisionne, ou alors, on doit disposer d'un contrat qui garantie dans tous
les termes possibles, que sur mon port Gb/s sur lequel je ne paye qu'au 95
percentile, en cas de dépassement, le fournisseur de "matière première"
s'engage à ce que ce transit soit disponible.

amicalement,

--
Christophe Casalegno | Groupe Digital Network | UIN : 153305055
http://www.digital-network.net | http://www.intelink.info
TISTC | OFREMHI | IIHEC | IICRAI | CIRET-AVT | KESAC | TIIX
Technical director | Security Intrusion techniques & infowar specialist.