Reprise du message précédent :

https://news.ycombinator.com/item?id=10746158 a une partie des critiques (il n'y a probablement pas eu de changement, dans la mesure où même le tableau de comparaison de prix n'a pas été mis à jour — S3 est 440% de B2 ou +340%)

Et si t'es dans un des clouds préexistants, IIRC t'as pas de coûts de bande passante en interne au réseau (ou t'as des réductions) genre S3 > EC2 dans la même zone c'est gratuit (et 0.02 pour une autre zone), idem si tu caches ton S3 via Cloudfront (tu paies Cloudfront mais pas S3 -> Cloudfront), etc… Si tu passes par B2, tu paies pour faire sortir les données de B2 et les utiliser dans ton WS.

j'ai cherché et j'ai pas trouvé rapidement, alors que c'est un point crucial pour ce genre de service, c'est super super louche en effet.

J'ai rien dans le cloud actuellement. Le but c'est uniquement d'y stocker des backups des clients XOA.

En gros, leur XOA (qui est notre appliance qui tourne CHEZ le client) va demander un upload, notre serveur va leur filer un token pour uploader directement, puis le XOA upload « au bon endroit » avec son token, sans passer par chez nous (qui serait un gros bottleneck)

Hmmff.. Dommage c'était vraiment pas cher

et sinon OVH ? https://www.ovh.com/fr/serveurs_ded [...] torage.xml
 
0,012€/GB pour 1TB
0,006€/GB pour 10TB
 
edit: ah non c'est pour les serveurs déjà hébergés chez eux je suis con

 
Vu mon expérience avec eux, je préfère pas (après j'suis peut être bête, mais là on parle de clients dans 30 pays différents déjà et potentiellement une volumétrie débit/stockage qui n'est pas neutre).

 
d'après les commentaires, pas de d'outil cli incremental, et pas de support Linux ? et ben...  la comparaison s'arrête là déjà pour moi. Éventuellement pour sauvegarder le contenu de son PC ou de son MAC ce qui semble être leur business pour le moment... mouaif

Dans mon cas c'est uniquement via API de toute façon, pas d'autre besoin (tant que je peux streamer avec Node dedans c'est OK)

 
1- quel est l'utilité du backup?
2- comment est monétisée ton offre aujourd'hui ? S3 n'est pas si excessif, ca rogne tant que ca votre marge ? Pas moyen de répercuter le prix au client ?

Si c'est pour du backup longue durée "oh shit", un stockage de longue durée peut être une option (genre glacier, ou même réparti sur 2-3 plateformes avec B2 en initial "accès rapide).
 
Selon le volume de données, ya tarsnap aussi

1. Éviter que le client paye/configure un serveur dédié, proposer une solution clef en main (incluse dans XOA) pour plannifier des backups de VM « à l'extérieur »
2. Pas encore monétisée, je suis en phase d'exploration technique (le besoin a été exprimé à plusieurs reprise par des clients). Ça sera repercuté au tarif de l'abo actuel (en « extra »). Reste à voir les détails de facturation pour pas se faire niquer.

Après, pour 8 To ça va me coûter 45€ contre 250€ chez Amazon, c'est ça qui me fait réfléchir à l'origine (ça c'est pour un potentiel client, quand y'en aura 50 je vous laisse imaginer l'écart de prix)

J'ai pas la main sur le comportement client. Faire du tiering chez nous c'est faisable (et intelligent) mais un peu complexe pour commencer.

La volumétrie dépendra aussi du client (et de son budget )

 
Voilà, Amazon propose des solutions moins coûteuses si c'est uniquement pour du backup.

 
8 To, c'est une valeur réaliste de ce que les clients actuels vont sauvegarder cette année ?

 
Je pense sincèrement que la volumétrie « moyenne » des clients va dépendre en partie de notre offre commerciale. J'ignore combien vont l'utiliser/souscrire, et pour quelle volumétrie moyenne.
 
Je sais que des soft concurrent proposent des tranches de 500 GiB, ce qui est un indicateur.
 
On va dans ce sens car c'est parfaitement dans notre stratégie (donner de la valeur à l'appliance XOA/le compte client sur xen-orchestra.com) tout en restant Open Source.

Personnellement, je n'optimiserais pas ce coût maintenant vu les données que tu as sur l'utilisation de ce service.
 
Ça sent le truc où la différence va être bouffée en temps de développeur aujourd'hui.

Oui, c'est ça qui pèse pas mal dans la balance, je risque de pas avoir de surprises avec S3 contrairement à d'autres

edit : après desfois les challengers sont mieux que les 1st, par exemple Paypal vs Stripe, on a fini par laissé tomber Paypal tellement c'était la merde leur API.

 
Je viens seulement de réaliser que static_cast peut avoir besoin de faire un test au runtime

quel genre de test ? il me semblait que non

Vraiment? Dans mon souvenir static_cast non, par contre tu peux l'overloader (via user-defined conversions) avec un truc qui fait des tests runtime.

C'est une code review qui m'a fait me poser la question. C'était un cas de ce genre :

Et ca m'a fait me demander si c'était valide de static_cast<>() quelque chose qui est potentiellement nullptr, sachant que tu dois changer le pointeur dans ce cas précis.
Et donc, vérification dans le standard (§5.2.9.11) :

Et vérification à l'appui, quand tu as un héritage de ce genre, le compilo fait un test du pointeur en entrée pour ne modifier l'adresse que si elle est non nulle.

Edit : Evidemment, dans un contexte d'héritage plus simple, le compilo ne génère aucun test.

ah ok, donc c'est juste un test sur le pointer null pour le laisser null c'est sain comme comportement

La réponse est : ça a marché \o/ on a besoin de chance des fois.

GG GROS

La chance c'est opportunité + travail + anticipation

https://medium.com/conquering-corpo [...] .nl8kfr1tz
 
On vient de me sortir un #6 en plein meeting, à froid, sur une question qui n'avait rien à voir.
C'était superbe, très bien exécuté

Il me semble que c'est assez galère de télécharger toute sa sauvegarde glacier d'un coup.

 
De toute façon je peux pas me permettre de partir sur du Glacier

http://rachelbythebay.com/w/2016/02/21/malloc/

 
Note to self: toujours ajouter des magic bytes au début des messages.

 
Et donc, ça scale ou pas ?

 
   
 
tellement ça.  

glacier c'est cool mais uniquement pour des trucs où tu peux te permettre d'attendre longtemps pour la récup. C'est du backup long terme, pour des VM qui tombent en panne et qui doivent être restaurées dans les minutes qui suivent, ça va pas du tout.

 
C'est exactement pour ça que c'est pas possible dans mon cas
 

 
Ils sont alignés sur les tarifs de "glacier" plutôt que "S3".
L'infra est homemade (les fameux "pod" ) repartie sur 2 DC (location bay area).
 
et je plussoie sligor sur le coups ... fais des tests et voit si ça te suffit.

sous entendrais-tu que d'habitude je dis de la merde ?

 
vu le "s" à "coup", je pense qu'il pensait cups.
 
ça doit avoir un sens caché.  

 
Selon le lien de machine même pas :  
https://news.ycombinator.com/item?id=10746158
 
 

 
 
Réponse de backblaze :

Ça sera donc S3 pour commencer

Tu signes un partenariat avec AWS et tu vends l'option avec un abo +  prix des ressources AWS + markup
 
Et tu utilises du reduced redundancy pour la première semaine et du glacier pour les trucs un peu vieux (avec un SLA différent).

 
c’était le sens voulu

 
tremblez ... c'est le début de la reforme de l'orthographe.

Woké, j'suis Vates encore, pas Citrix

Ensuite, on peut pas vraiment faire comme ça pour les backups anciens, car on fait un backup delta incrémental continu (ouf). Cf https://xen-orchestra.com/docs/delt [...] continuous

Donc le plus ancien delta doit être lu pour être mergé dans le « full » disk (qui doit être lu aussi en partie, les en-têtes)

Sinon pour l'archi globale, on pensait plutôt générer un token lié au XOA pour que le client puisse uploader dans une « zone » à lui. Bref, qu'il n'y ai rien à faire de son côté (il peut ne même pas savoir qu'il y a un S3)

 
effectivement : https://www.backblaze.com/blog/our-secret-data-center/