wilk a écrit 1102 commentaires

Je ne comprends trop l'intérêt de calculer en terme de datacenter. Autant qu'un datacenter parte en fumé c'est assez rare, autant qu'une machine ou encore mieux qu'une vm parte en fumée ça arrive tous les jours. Et pour l'utilisateur c'est ce qui compte, peu importe que les serveurs d'à côté partent en fumée aussi, il en suffit d'un et que ce soit le notre…
L'article met bien l'accent sur le fait de gérer plus ou moins soit-même la redondance.
Il me semble que c'est à ce niveau qu'il faut faire des comparaisons et quitter ou non OVH. C'est à dire dans les services disponibles sur l'infrastructure proposée pour pouvoir gérer cette redondance.
Hors c'est bien à ce niveau que le leader distance complètement les suivants, ça me semble même sans commune mesure.
Eventuellement on peut palier à ça avec des compétences internes, mais on ne compare plus du tout la même chose et encore moins le coût final.
En tout cas bravo à Cozy pour avoir réussi cet exploit, et on peut préciser "en particulier chez OVH" ! Chez l'autre il n'y aurait eu aucun mérite !

edit: pour ceux qui voudraient se rendre compte, regardez les possibilités d'une BDD Aurora par ex, et imaginez faire la même chose chez OVH (ou autres)…

Je ne peux pas l'expliquer pour le moment, je l'ai trouvé par tâtonnement (je me suis fait un défi de passer de websocket à sse dans la journée en prod !)… Ce qui a été délicat c'est qu'en local je testais en accès direct à mon application, et en prod par Nginx. Je n'ai pas encore testé si ça passe par un load balancer type ELB…

Maintenir un version web et une version desktop risque d'être assez lourd non ? Est-ce que l'objectif à terme est de n'en conserver qu'une ?

Ton article m'a donné envie d'essayer les SSE pour remplacer un système de websocket que je n'utilisais que dans un sens (serveur vers client et classique dans l'autre sens).

Il y a quelques années pour apprendre le langage Go j'avais réécris un système de websocket en Python (pour un jeu de scrabble) qui fonctionnait mais il m'était impossible de faire évoluer ce code spaghetti. Le résultat était déjà plutôt concluant, mais plat de pâte tout de même.
Du coup je viens de le réécrire avec SSE.
Première chose plus besoin de dépendre d'une lib externe (gorilla.websocket) et pas mal de code de tuyauterie à supprimer autant côté serveur que client.
Ensuite le côté sens unique de SSE correspond exactement au fonctionnement des channels en Go. Ce qui fait que mon dispatcher fonctionne aussi bien avec des clients distants (un client SSE = un channel) ou des goroutines (par exemple un robot joueur).
En Python j'avais séparé mon appli en plusieurs services (les robots à part) qui communiquaient par websocket, et la du coup je les ais réintégrés dans la même application et ils communiquent par channel sans changer grand chose au code, ça me laisse le choix.
Bref, les SSE sont un excellent moyen de familiariser aux concepts de channel en Go.

A part ça, j'ai eu quelques surprises niveau Nginx.
Dans un premier temps je me suis dit, avec http ça va aller tout seul. Effectivement ça semble fonctionner tout seul.
Mais en regardant les logs je me suis aperçu que la connexion était coupée toutes les minutes.
J'ai rajouté ça :

proxy_buffering off;
proxy_cache off;
proxy_set_header Connection '';
proxy_http_version 1.1;
chunked_transfer_encoding off;

Tout allait bien jusqu'à ce que des joueurs se plaignent que ça rame, ce que n'avais pas constaté dans mes essais. Après enquête je comprends que c'est quand on ouvre plusieurs onglets. J'essaye d'ouvrir une dizaine d'onglets, l'ordinateur se met à souffler comme un malade et les derniers onglets tournent sans rien afficher. Systématiquement à partir du sixième ! J'essaye un autre navigateur, pareil, 6 onglets max.
C'est finalement une limitation http, je trouve enfin qu'il faut passer en http2

server {
listen 443 ssl http2;

Tout semble rentrer dans l'ordre.

Bilan, les SSE en Go c'est un régal, je garde.

Ce qu'il faudrait expliciter vraiment (si j'ai bien compris), c'est que une fois le socket "ouvert", le serveur peut être à l'initiative d'un message vers le client, ce qui est normalement réservé au client. En fait, on peut faire un vrai "push" ici : pour recevoir des données du serveurs, on ne contente pas d'attendre le retour de requêtes envoyées au serveur. Le serveur peut de lui même initier des requêtes vers le client. Je suppose que cela sous-entend une prise en charge particulière dans les proxies et NAT.

Je pense que tu as bien compris le but de la manœuvre. Je fais un petit retour d'xp dans un autre fil, ça répondra peut-être à tes questions.

A propos du code, un truc qui m'a perturbé quand j'ai regardé (y a longtemps), c'est les noms des tables et champs PostgreSQL en majuscule, ça oblige à les mettre entre guillemet ce qui n'est pas toujours pratique… D'où vient cette idée ?

J'utilise https://github.com/kopia/kopia ça permet à la fois d'envoyer sur S3 en même temps c'est dédupliqué, compressé, incrémental etc… Sinon en rclone marche très bien aussi.

Clairement je ne vois pas du tout comment les "petits" (pas si petits déjà !) peuvent y arriver, surtout qu'ils essayent de jouer sur les prix et du coup se privent de pouvoir investir ou faire de la qualité, c'est le cercle vicieux…
Pas évident dans ce contexte d'être clair et sans baratin. Je trouve que Hetzner le fait assez bien, il ne propose pas ce qu'il ne sait pas encore faire. Tandis que les deux nôtres peinent à essayer de faire semblant que…
En tout cas c'est mal barré car la barre est de plus en plus haute et monte plus vite que ceux qui essayent de suivre.

Je cite :

Actuellement, les données de notre service d'Object Storage ne sont pas redondées sur différentes AZ ou même régions.
Suite aux différentes demandes clients, sur notre plateforme "Feature Request"
(https://feature-request.scaleway.com/posts/110/object-storage-replication-between-many-regions), cette fonctionnalité va être implémentée, mais je ne peux
vous communiquer d'ETA.

Inutile de demander pour les bases de données avec l'option HA, c'est écrit "Nous nous assurons également que vos instances fonctionnent sur des hyperviseurs différents", donc c'est clairement pas séparé physiquement.

Chez l'autre quand on crée une BDD il demande : c'est pour des tests ? Non, alors activez tout de suite la réplication multi AZ. Et si vous êtes sérieux cochez la case réplication à l'autre bout de l'Europe en plus (c'est assez récent par contre).

Dans sa dernière vidéo Octave prétend qu'il va faire évoluer le milieu industriel dans son ensemble… Non, mais s'il te plait laisse le milieu industriel en dehors !

Bon, le chef de niveau 2 a répondu, chez Scaleway les objets de type S3 c'est S3 dans le même panier bien au chaud. Il m'invite à suggérer la fiture sur le forum ad hoc et en attendant à cloner mes objets moi-même.

On est tellement à des années lumière de l'autre à 3 lettres… pfiouuu…

Du coup on déclare quoi ? Que les données des clients qui étaient dans le cloud sont maintenant dans les nuages (mais là c'est sûr elles vont y rester) ?

Suite à cet article :
https://blog.scaleway.com/how-we-protect-your-data/

Je viens de demander chez Scaleway si le stockage objet est répliqué 3x sur des datacenters éloignés géographiquement et à quelle distance.
Réponse du support : "Je vérifie auprès de nos techniciens de niveau 2."

…Chef chef, on ne stocke quand même pas les objets 3x au même endroit hein ? Je lui répond quoi au client ?

Jamais vu une option payante pour vérification des sauvegardes…

Prochain drame psychologique : nous rappelons qu'il était de la responsabilité du client de vérifier les sauvegardes.

Les mails (ou autres messageries directes) remplacent de plus en plus souvent des conversations et des réunions en chair et en os. Hors on n'enregistre pas ces conversations pour les ressortir "t'avais dit ça…". Ce qui ressort de ces conversations éventuellement on en fait un résumé que l'on classe dans le projet ad hoc.
Je fais pareil avec les mails, je les empile sur le bureau tant qu'ils ne sont pas traités, certains je les range dans un carton, la plupart finissent à la poubelle à plus ou moins brève échéance. Bref, j'en conserve très peu et pas longtemps.
Du coup peu importe le client mail. J'utilise vim comme un crayon, pour tout. Et mutt comme un vulgaire bureau avec quelques tiroirs.

Merci pour ces explications.
Un truc qui m'a aidé à comprendre et utiliser Git (j'utilisais plutôt Mercurial) c'est un tuto où on écrit un proto en Python :
https://www.leshenko.net/p/ugit/
J'adorerai voir la même chose avec Pijul !

D'où vient le fait que l'implémentation à l'air si longue ?
Je me souviens qu'à l'époque ou Git est né, mercurial, arch, tla, bazaar… il ne semblait pas si difficile d'implémenter de nouvelles idées de dvcs.
Est-ce le principe en lui-même où ça n'a rien à voir ?
Je ne pense quand même pas non plus que ça vienne de Rust ?

Moi je serai à ta place j'aurai donné mon numéro de portable.

-Merci de bien vouloir me donner votre numéro de portable.
-Impossible je l'ai déjà donné à Stripe hier (je vais quand même voir s'ils ne peuvent pas me le rendre).

Ce que trouve curieux c'est l'argument comme quoi il faudrait faire face à "la concurrence de Google avec golang".

On ne sais pas trop si c'est un problème par rapport à Google ou par rapport à un autre langage (Go et non pas golang et libre lui aussi).
Enfin si on se doute "langage golang de Google dont le succès croissant menace le leadership de "Python""

ps: Guido bosse maintenant chez Microsoft, juste parce qu'il s'ennuyait à la retraite !

https://www.zdnet.fr/actualites/guido-van-rossum-le-fondateur-du-langage-python-rejoint-microsoft-39912909.htm

En Go, le pattern c'est de retourner (resultat, erreur). Si tu ne verifies pas l'erreur, dommage le compilateur ne t'aidera pas à t'en rendre compte

Je n'ai jamais compris pourquoi ça n'était pas une obligation (de traiter l'erreur retournée). Ne serait-ce que d'indiquer _ = si vraiment on ne veut pas, mais au moins ce serait explicite.
Quelqu'un sait la raison ?

Les avantages c'est qu'il fait tout ce que font les autres, plus une UI, très rapide etc… Un peu trop (compliqué) à mon avis d'ailleurs.
L'inconvénient (et l'avantage, le développeur est vraiment très réactif) c'est que c'est jeune et que ça évolue beaucoup donc trop tôt pour savoir si c'est fiable, il n'est pas encore en v1.
Pour l'instant j'utilise borg et kopia en //.
Il est éventuellement prévu que kopia soit scindé en une lib + une UI. Ce que je préférerais pour développer un outil plus simple maison par dessus.

Restic ne fait s3 mais pas la compression, borg fait la compression mais pas s3, kopia fait les deux.

Un petit nouveau dans la famille restic/borg : kopia
https://github.com/kopia/kopia
Il regroupe les fonctionnalités que les deux précédents ne font pas : compression et stockage type S3. En prime il est plus rapide…

Sinon mon principe, comme déjà dit par d'autres, c'est de différencier le type de sauvegarde par type de données.
Mes photos comme elles ne sont ni compressable ni deduplicable je les envois sur S3 avec versionning.
Mon boulot, je push sur un dépot distant avec un hook à chaque commit. Je lance lance kopia toutes les heures sur mon home de travail, c'est surtout pour le cas où je supprime un fichier par erreur dans la journée.
Et enfin j'ai craqué, j'envoi un tas de trucs sur S3…

Le mieux c'est quand j'ai effacé tous les mails d'un client car on s'était mal compris. Je n'ai pas eu le temps de lui dire que j'avais une sauvegarde, il m'a remercié, il m'a dit que ça lui avait changé la vie, qu'il se sentait rajeunir, tout ça… Depuis je ne sauvegarde plus mes mails !

D'abord bravo et merci pour ces contributions remarquables ! L'investissement humain doit être considérable. Et du coup ça m'amène à toussoter sur ces mentions :

• Capacité à gérer un nombre élevé d'instances et d'utilisateurs.

• Coût exceptionnellement bas (doit être au moins 10 fois inférieur aux solutions Cloud par conteneurs).

Hors en survolant la documentation sur l'installation j'ai plutôt l'impression que le coût du déploiement et de la maintenance est au contraire largement supérieur aux solutions Cloud si on tien compte du coût humain. Je me trompe ?

https://github.com/eldy/sellyoursaas/blob/master/doc/Documentation%20SellYourSaas%20-%20Master%20and%20Deployment%20Servers%20-%20FR.asciidoc

Ca me fait penser aux petits commerçants qui veulent des parkings comme les grands. Au lieu de capitaliser sur leur particularités bien à eux ils se tirent des balles dans le pied et après ça fait mal.