Non, au contraire, c'est comme ça que fonctionne Aurora (AWS). Quelque soit l'architecture utilisée il y a toujours une gestion de cache d'ailleurs.
Plus la charge va être forte plus le cache va jouer à priori. Inversement c'est surtout pour les petites charges qu'il y a du démarrage à froid (Aurora v2 ne scale plus à zéro comme la v1 du coup).
A suivre…
Il y a une couche intermédiaire qui sert de cache. J'imagine que le problème va se poser sur des grosses bases où d'un coup on va vouloir tirer des infos "froides"…
Pour l'instant en beta test on a droit qu'à des toutes petites bases.
Y a les deux côtés, le côté interne c'est ça, l'instance POstgresql est découplée du stockage voir inexistante, c'est le vrai serverless si on considère que le stockage ça n'est pas du serveur.
Et le côté service, là c'est serverless pour le client mais pas pour le fournisseur où là pour le coup c'est du servermore vu qu'il va avoir un serveur pour le stockage, un pour la couche intermédiaire, un pour le moteur, un pour l'api etc !
ps: pour l'instant je ne crois pas qu'il y ait de read-replicas, donc une seule instance ou zéro, mais c'est prévu ainsi que le scaling vertical automatique (pour ne pas avoir à choisir le type d'instance).
Vu que le stockage est à part la base et les branches existent même si aucun moteur n'est lancé.
Since storage is separate, compute, which is a Postgres process, becomes stateless (barring the buffer cache). This allows dynamically rescheduling compute and moving it from one node to another.
Lancement prochain du mode autopilot. Plus besoin de tweeter soit-même. Grace à une IA, nommée KePenserDe, on pourra tweeter sans même avoir besoin d'être réveillé. Enfin des débats "sains" et non plus souillés par notre propre pensée archaïque soumise aux aléas biologiques d'un autre temps.
Bien vu, apparemment c'est un problème qui n'est pas résolu et qui concerne pas mal d'autres frameworks, y a une recherche de consensus au niveau w3 pour permettre que des attributs persos soient valides mais c'est pas encore le cas. Théoriquement il faudrait utiliser quelque chose qui commence par data-. Je ne sais pas si c'est possible de le configurer…
Désolé j'ai raté l'option, c'est une migration d'une boite française mais c'est pas en français…
A part ça je peux aussi témoigner sur l'intérêt de cette petite lib qui permet d'ajouter un peu de réactivité aux pages sans renier la logique du rendu serveur… Que du bonheur.
Dernier truc rigolo en date, en récupération de billet (acheté sur TER et transféré sur l'appli) il n'en récupère qu'un sur 4 et me l'affiche avec 2h en moins ! Ca sent le problème de timezone… J'imprime…
C'est que maintenant les gens sont tellement habitués à voir des applis pleins de bugs que soit mon appli en à aussi et c'est normal c'est comme ça, comme les grands, soit elle n'en n'a pas (et en plus elle est rapide) et je passe pour un génie !
edit:
Et maintenant je pourrai dire à mes clients, attention si vous ne testez pas la beta ça va finir comme à la SNCF.
J'ai trouvé le graal du serverless sans la contrainte de réécrire les apps ! Ca s'appelle Knative, ça scale de zéro… Je dis knative pour ne pas citer Scaleway et CloudRun qui le proposent « as a service ». Le principe est simple, l'application doit écouter sur le port 8080 comme n'importe quel serveur http.
Longtemps j'étais réticent à quitter l'infra à la papa où rien n'a changé ou presque sous le capot depuis 30 ans et qui permet de comprendre ce qui se passe et agir à tous les niveaux. Mais là j'avoue, c'est bluffant. Git push et voilà.
L'avantage du Go dans ce cas il est simple, un Dockerfile avec un distroless on ne plus simple et le démarrage à froid se fait dans la seconde, une empreinte mémoire ridicule, un cpu qui reste au raz des pâquerettes. Tout ce qu'il faut pour faire un serveur http est dans la lib standard, même les templates html, même l'embarquement des assets dans le binaire !
Autre avantage de Go c'est de pouvoir jongler soit avec des goroutines+channel en interne soit reproduire exactement la même chose en microservices séparés (les channels sont à sens unique). Il m'est arrivé plusieurs fois de passer de l'une à l'autre méthode en changeant quelques lignes de code simplement.
Niveau de la simplicité du langage personnellement ça me rappelle le C de ma jeunesse, que de bons souvenirs !
Bref, à part la partie cachée du serverless, je retrouve le côté simple d'unix un binaire qui vet voilà.
Tellement rapide. Je modifie un fichier, j'enregistre, le code est formaté, les imports ajustés, les erreurs de types détectées, le temps d'aller sur le bureau d'à côté et de recharger ma page le bouzin est déjà recompilé. C'est plus rapide que quand de relancer un serveur python !
Je viens d'essayer sur un vieux code, le résultat est assez précis :
Vulnerability #1: GO-2021-0052
Due to improper HTTP header santization, a malicious user can
spoof their source IP address by setting the X-Forwarded-For
header. This may allow a user to bypass IP based restrictions,
or obfuscate their true source.
Call stacks in your code:
main.go:71:12: godepot.main calls github.com/gin-gonic/gin.Engine.Run
Donc j'ai l'explication de la vulnérabilité et la ligne de code où j'appelle la fonction dans la lib vulnérable.
Si j'enlève ma ligne de code je n'ai plus d'alerte.
J'ai le choix entre modifier mon app ou mettre à jour la lib.
Ensuite j'obtiens également des infos sur des problèmes que je pourrai rencontrer mais à priori pas.
=== Informational ===
The vulnerabilities below are in packages that you import, but your code
doesn't appear to call any vulnerable functions. You may not need to take any
action.
HP n'est plus ce que c'était, les trois dernières, une laser et deux jets d'encre que j'ai eu m'on énormément déçu.
La dernière blague c'est que les cartouches originales HP ont une date de péremption même sous blister ! Donc tu as acheté une cartouche de plus pour en avoir en réserve, tu la mets et elle te dit qu'il ne vaut mieux pas, que ça risque d'endommager ton imprimante. Tu appelles le support pour les rassurer sur le fait que tu prends l'entière responsabilité d’abîmer ton imprimante, mais non, rien à faire, c'est écrit dessus t'avais qu'à regarder.
L'automobiliste écolo, il laisse le moteur allumé pour ne pas couper la clim, ainsi il peut éviter une douche.
Sinon franchement quand il fait bien chaud dehors on transpire beaucoup plus en voiture qu'à vélo à allure pépère.
Les bains glacés en Norvège c'est le top. Mais on s'écarte un peu du côté éco-geste ! Alors on se console comme on peut avec une petite douche froide quotidienne.
Froides froides, glacées si possible !
Du coup ça entraîne une autre réaction que juste une sensation de température et c'est ce que j'aime bien. Une réaction genre éclat de rire et en hiver ça se transforme même rapidement en sensation de chaud…
Mais si je ne suis pas en forme je ne me force pas et dans ce cas je la prend chaude normale, je n'aime pas trop l'entre deux. En été c'est un problème du coup parfois je laisse un peu couler l'eau pour qu'elle se refroidisse !
Le plus efficace c'est de militer sur les bienfaits des douches froides (santé, prospérité, retour de l'être aimé etc.). J'ai réussi à convaincre une des 3 chevelues aussi grace au côté « t'es cap ? ».
Une fois la santé, la prospérité et l'être aimé revenu on peut actionner le côté éco-geste.
le développement => 8.3 + 12.6 = 21 millions, ça ne me paraît pas hallucinant.
On parle de vente de billet de train, un formulaire principal, arrivée-départ (oui dans cet ordre !), une date.
A l'époque de captaintrain j'ai bossé pour un concurrent, on était 3 dev + 1 ops, l'algo de recherche d'itinéraires (jusqu'à 6 correspondances !), 1500 lignes de code. Chez Captaintrain ils n'étaient pas beaucoup plus nombreux.
Chez oui.sncf ils étaient 10 devs l'année dernière.
Là ils sont 200 devs pour une appli mal foutue et qui ne marche pas. Je trouve donc ça bel et bien hallucinant.
Des équipes qui se parlent ? Et pourquoi pas un décideur qui les écoute pendant qu'on y est ?
Hahaha, oui, évidement tu as tout à fait raison, d'où l'intérêt du chat de Scalingo… Je continue ma progression…
[^] # Re: S3 ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches . Évalué à 2.
https://cloud.google.com/blog/products/databases/announcing-the-general-availability-of-alloydb-for-postgresql
Idem chez l'autre.
[^] # Re: S3 ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches . Évalué à 2.
Non, au contraire, c'est comme ça que fonctionne Aurora (AWS). Quelque soit l'architecture utilisée il y a toujours une gestion de cache d'ailleurs.
Plus la charge va être forte plus le cache va jouer à priori. Inversement c'est surtout pour les petites charges qu'il y a du démarrage à froid (Aurora v2 ne scale plus à zéro comme la v1 du coup).
A suivre…
[^] # Re: S3 ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches . Évalué à 3.
Il y a une couche intermédiaire qui sert de cache. J'imagine que le problème va se poser sur des grosses bases où d'un coup on va vouloir tirer des infos "froides"…
Pour l'instant en beta test on a droit qu'à des toutes petites bases.
[^] # Re: Serverless ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches . Évalué à 3.
Y a les deux côtés, le côté interne c'est ça, l'instance POstgresql est découplée du stockage voir inexistante, c'est le vrai serverless si on considère que le stockage ça n'est pas du serveur.
Et le côté service, là c'est serverless pour le client mais pas pour le fournisseur où là pour le coup c'est du servermore vu qu'il va avoir un serveur pour le stockage, un pour la couche intermédiaire, un pour le moteur, un pour l'api etc !
ps: pour l'instant je ne crois pas qu'il y ait de read-replicas, donc une seule instance ou zéro, mais c'est prévu ainsi que le scaling vertical automatique (pour ne pas avoir à choisir le type d'instance).
[^] # Re: Serverless ?
Posté par wilk . En réponse au journal Neon : Postgresql serverless avec branches . Évalué à 3.
Oui, en tout cas c'est comme ça qu'ils le décrivent https://neon.tech/blog/hello-world/
Vu que le stockage est à part la base et les branches existent même si aucun moteur n'est lancé.
# Suivi
Posté par wilk . En réponse au lien Le Courrier du hacker (n°199) - de Twitter vers Mastodon. Évalué à 3.
Ils ont déjà des mails @assemblee-nationale.fr, et il est possible de migrer vers une autre instance avec un suivi non ?
# Pilotage automatique
Posté par wilk . En réponse au lien Le milliardaire Elon Musk a pris le contrôle de Twitter et licencié des dirigeants. Évalué à 5.
Lancement prochain du mode autopilot. Plus besoin de tweeter soit-même. Grace à une IA, nommée KePenserDe, on pourra tweeter sans même avoir besoin d'être réveillé. Enfin des débats "sains" et non plus souillés par notre propre pensée archaïque soumise aux aléas biologiques d'un autre temps.
[^] # Re: Validité de l'HTML ?
Posté par wilk . En réponse au lien Migration de react vers htmx. Évalué à 4. Dernière modification le 20 octobre 2022 à 09:13.
Bien vu, apparemment c'est un problème qui n'est pas résolu et qui concerne pas mal d'autres frameworks, y a une recherche de consensus au niveau w3 pour permettre que des attributs persos soient valides mais c'est pas encore le cas. Théoriquement il faudrait utiliser quelque chose qui commence par
data-. Je ne sais pas si c'est possible de le configurer…# SPA en français
Posté par wilk . En réponse au lien Migration de react vers htmx. Évalué à 6.
Désolé j'ai raté l'option, c'est une migration d'une boite française mais c'est pas en français…
A part ça je peux aussi témoigner sur l'intérêt de cette petite lib qui permet d'ajouter un peu de réactivité aux pages sans renier la logique du rendu serveur… Que du bonheur.
[^] # Re: Histoire de casser du sucre
Posté par wilk . En réponse au lien Dans les coulisses produit de SNCF Connect, l’appli qui a déraillé au départ. Évalué à 7.
Dernier truc rigolo en date, en récupération de billet (acheté sur TER et transféré sur l'appli) il n'en récupère qu'un sur 4 et me l'affiche avec 2h en moins ! Ca sent le problème de timezone… J'imprime…
# Le bon côté
Posté par wilk . En réponse au lien Dans les coulisses produit de SNCF Connect, l’appli qui a déraillé au départ. Évalué à 6. Dernière modification le 24 septembre 2022 à 21:18.
C'est que maintenant les gens sont tellement habitués à voir des applis pleins de bugs que soit mon appli en à aussi et c'est normal c'est comme ça, comme les grands, soit elle n'en n'a pas (et en plus elle est rapide) et je passe pour un génie !
edit:
Et maintenant je pourrai dire à mes clients, attention si vous ne testez pas la beta ça va finir comme à la SNCF.
# Knative, le graal.
Posté par wilk . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 4.
J'ai trouvé le graal du serverless sans la contrainte de réécrire les apps ! Ca s'appelle Knative, ça scale de zéro… Je dis knative pour ne pas citer Scaleway et CloudRun qui le proposent « as a service ». Le principe est simple, l'application doit écouter sur le port 8080 comme n'importe quel serveur http.
Longtemps j'étais réticent à quitter l'infra à la papa où rien n'a changé ou presque sous le capot depuis 30 ans et qui permet de comprendre ce qui se passe et agir à tous les niveaux. Mais là j'avoue, c'est bluffant. Git push et voilà.
L'avantage du Go dans ce cas il est simple, un Dockerfile avec un distroless on ne plus simple et le démarrage à froid se fait dans la seconde, une empreinte mémoire ridicule, un cpu qui reste au raz des pâquerettes. Tout ce qu'il faut pour faire un serveur http est dans la lib standard, même les templates html, même l'embarquement des assets dans le binaire !
Autre avantage de Go c'est de pouvoir jongler soit avec des goroutines+channel en interne soit reproduire exactement la même chose en microservices séparés (les channels sont à sens unique). Il m'est arrivé plusieurs fois de passer de l'une à l'autre méthode en changeant quelques lignes de code simplement.
Niveau de la simplicité du langage personnellement ça me rappelle le C de ma jeunesse, que de bons souvenirs !
Bref, à part la partie cachée du serverless, je retrouve le côté simple d'unix un binaire qui vet voilà.
[^] # Re: Go remplace Java
Posté par wilk . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 6.
Tellement rapide. Je modifie un fichier, j'enregistre, le code est formaté, les imports ajustés, les erreurs de types détectées, le temps d'aller sur le bureau d'à côté et de recharger ma page le bouzin est déjà recompilé. C'est plus rapide que quand de relancer un serveur python !
[^] # Re: infos complémentaires
Posté par wilk . En réponse au lien Go propose une base de données vulnérabilités (vuln) dans vos dépendances (modules). Évalué à 5.
Je viens d'essayer sur un vieux code, le résultat est assez précis :
Donc j'ai l'explication de la vulnérabilité et la ligne de code où j'appelle la fonction dans la lib vulnérable.
Si j'enlève ma ligne de code je n'ai plus d'alerte.
J'ai le choix entre modifier mon app ou mettre à jour la lib.
Ensuite j'obtiens également des infos sur des problèmes que je pourrai rencontrer mais à priori pas.
[^] # Re: C'est pourtant simple
Posté par wilk . En réponse au journal Sobriété, j'écris ton nom. Évalué à 3.
Ce ne nous rajeunit pas tout ça.
# HPlus jamais
Posté par wilk . En réponse au message Achat d'imprimante : Laser ou Jet d'encre ?. Évalué à 10.
HP n'est plus ce que c'était, les trois dernières, une laser et deux jets d'encre que j'ai eu m'on énormément déçu.
La dernière blague c'est que les cartouches originales HP ont une date de péremption même sous blister ! Donc tu as acheté une cartouche de plus pour en avoir en réserve, tu la mets et elle te dit qu'il ne vaut mieux pas, que ça risque d'endommager ton imprimante. Tu appelles le support pour les rassurer sur le fait que tu prends l'entière responsabilité d’abîmer ton imprimante, mais non, rien à faire, c'est écrit dessus t'avais qu'à regarder.
[^] # Re: Douches froides
Posté par wilk . En réponse au journal économie d'electricité. Évalué à 6.
L'automobiliste écolo, il laisse le moteur allumé pour ne pas couper la clim, ainsi il peut éviter une douche.
Sinon franchement quand il fait bien chaud dehors on transpire beaucoup plus en voiture qu'à vélo à allure pépère.
[^] # Re: Douches froides
Posté par wilk . En réponse au journal économie d'electricité. Évalué à 1.
Les bains glacés en Norvège c'est le top. Mais on s'écarte un peu du côté éco-geste ! Alors on se console comme on peut avec une petite douche froide quotidienne.
[^] # Re: Douches froides
Posté par wilk . En réponse au journal économie d'electricité. Évalué à 1.
Froides froides, glacées si possible !
Du coup ça entraîne une autre réaction que juste une sensation de température et c'est ce que j'aime bien. Une réaction genre éclat de rire et en hiver ça se transforme même rapidement en sensation de chaud…
Mais si je ne suis pas en forme je ne me force pas et dans ce cas je la prend chaude normale, je n'aime pas trop l'entre deux. En été c'est un problème du coup parfois je laisse un peu couler l'eau pour qu'elle se refroidisse !
# Douches froides
Posté par wilk . En réponse au journal économie d'electricité. Évalué à 4.
Le plus efficace c'est de militer sur les bienfaits des douches froides (santé, prospérité, retour de l'être aimé etc.). J'ai réussi à convaincre une des 3 chevelues aussi grace au côté « t'es cap ? ».
Une fois la santé, la prospérité et l'être aimé revenu on peut actionner le côté éco-geste.
[^] # Re: auto promo
Posté par wilk . En réponse au lien Comparatif open-source Drupal vs. Wordpress. Évalué à 7.
Bienvenu dans ce cas. Si tu connais le sujet autant rédiger une dépêche ou un journal ce sera plus instructif.
[^] # Re: 50 M€
Posté par wilk . En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à 10.
On parle de vente de billet de train, un formulaire principal, arrivée-départ (oui dans cet ordre !), une date.
A l'époque de captaintrain j'ai bossé pour un concurrent, on était 3 dev + 1 ops, l'algo de recherche d'itinéraires (jusqu'à 6 correspondances !), 1500 lignes de code. Chez Captaintrain ils n'étaient pas beaucoup plus nombreux.
Chez oui.sncf ils étaient 10 devs l'année dernière.
Là ils sont 200 devs pour une appli mal foutue et qui ne marche pas. Je trouve donc ça bel et bien hallucinant.
Y a un devoxx :
https://www.youtube.com/watch?v=dPfREPMacYc
[^] # Re: que du bon
Posté par wilk . En réponse au lien Mozilla nomme Steve Teixeira comme nouveau chef de produit. Évalué à 8.
Tu as raison, il est effectivement curieux que Mozilla ne recherche pas quelqu'un de compétent et d'expérience dans le domaine qui est le sien.
https://www.mozilla.org/fr/about/manifesto/
[^] # Re: conclusion d'expert
Posté par wilk . En réponse au lien Une étude révèle les langages les plus voraces en énergie. Évalué à 8.
C'est déjà le cas, les langages polluants sont eux même des programmes écrits en C.
[^] # Re: Chez moi Scalingo ça marche
Posté par wilk . En réponse au journal Scalingo & co, ça PAAS ou ça casse ?. Évalué à 10.
Des équipes qui se parlent ? Et pourquoi pas un décideur qui les écoute pendant qu'on y est ?
Hahaha, oui, évidement tu as tout à fait raison, d'où l'intérêt du chat de Scalingo… Je continue ma progression…