Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash, je suis Patrick, je suis heureux
de vous retrouver et comme d'habitude nous sommes avec Alex, salut Alex !
Salut Patrick, salut tout le monde ! Désolé j'ai un petit fouillir parce qu'on rigole
justement. Donc aujourd'hui épisode spécial hébergement, donc on va faire un épisode où
on va parler des hébergements, des solutions pour héberger vos applications, PHP, Go, Node,
tout ce que vous voulez. Donc on a différentes catégories et on va voir, j'expliquer les
différentes catégories, comment ça fonctionne etc. Et donc voilà, ça va Alex ?
On va parler de VPS, de PAS, de BAS. Tout ces acronymes impossibles, essayer de
clarifier pour voir en fait qu'est-ce que c'est, pour qui, les avantages, les
inconvénients et toutes ces solutions. Et ben on attaque ! La plus grosse partie,
on va dire la première catégorie c'est quoi ? La première catégorie en fait, c'est la catégorie
qu'on utilise depuis toujours en fait, c'est voilà depuis que le web existe, depuis que les
sociétés font des grosses sites etc. C'est de louer en fait des serveurs qui sont bruts,
où tu vas installer ce que tu veux dessus. Donc aujourd'hui on a des machines virtuelles,
c'est segmenté sur des serveurs, donc tu achètes un petit bout de serveurs, tu définis
combien tu veux de RAM, combien tu veux de processeurs etc. de stockage et tout. Et puis après tu
accèdes en SSH et c'est parti, tu installes tout ce que tu veux. Et donc du coup là je dois gérer,
je vais mettre mon système d'exploitation, donc ça peut être Linux, ça peut être ce que je
veux. Et derrière je vais installer mes paquets classiques. Et en fait ok. Donc j'ai un accès
full à la machine quoi. Ouais, tu es totalement responsable de ta machine. Donc dans ce cas là,
souvent si tu as un problème technique, ils sont pas là pour t'aider, parce que c'est ta machine,
donc c'est comme si ton ordi perso, tu as un problème, bah tout débrouille quoi. Donc il n'y a
pas de problème, après il y a peut-être des petits forfaits qui peuvent t'assister je sais pas.
Mais la plupart du temps tu es vraiment seul face à la machine et tu dois tout configurer. C'est
une boîte noire quoi. Ok, donc ce qui veut dire que j'ai une grande liberté, mais ça veut dire aussi
que j'ai une grande responsabilité. Donc ça veut dire que j'ai un niveau et une barrière à
l'entrée qui est un peu élevée. Parce que si moi je suis rookie, je connais rien, je suis junior,
configurer une machine c'est quand même hyper spécial. Et comment je vais articuler tout mon
backend, mon front, ma base de données. Si en plus je veux déployer avec Git, tout ça, c'est moi
qui fais tout. Bah ouais c'est toi qui fais tout. Donc c'est pour ça que c'est un peu des inconvénients
en fait. De suite par des inconvénients. C'est vraiment la barrière à l'entrée est assez
haute quoi. C'est qu'il faut être vraiment très compétent pour régler un serveur, installer les
choses et surtout sécuriser le serveur pour pas que quelqu'un puisse entrer par une backdoor ou
n'importe quoi, par un système qui n'est pas bien configuré. Je me rappelle à l'époque qu'il y avait
eu les bases de données MongoDB qui étaient ouvertes par défaut et tu pouvais trouver plein d'entrée
sur le web par des gens qui n'avaient pas configuré correctement. Donc souvent c'est souvent la
sécurité qui est très compliquée à régler. C'est ce qu'on demande d'ailleurs la plupart du temps.
Même si aujourd'hui il y a quand même pas mal de services, des outils open source qui nous
permettent de faire des certificats assez rapidement et assez facilement. Mais ça reste quand même de
souvent ça demande d'avoir des personnes dédiées à ça soit en interne soit en externe c'est
obligatoire. Quelqu'un qui gère l'infra. Donc il y a des sociétés qui passent par des prestataires
externes, des DevOps qui vont tout configurer, tout régler, tout surveiller et quand tu auras besoin
de faire une modif, tu vas lui demander, il va faire soit t'es une grosse société et tu as carrément
des DevOps en interne qui vont gérer les serveurs, tu as une équipe dédiée, après ça dépend du
object, ça dépend de la taille des projets etc. Et donc du coup en fait je vais provisioner ces
machines là et après je vais utiliser pour mon service de déploiement, pour déployer toutes
mes applications, j'utilise Docker, Kubernetes, tout ça, toutes ces stacks là, elles vont se
mettre en fait sur des machines en direct. Après c'est toi qui fais, tu utilises ce que tu veux de façon.
Ok, du coup ça limite quand même l'accès technique, c'est pas ouvert à tout le monde.
Non c'est pas ouvert à tout le monde et par contre après il y a des davantage, il y a quand même pas
mal d'avantage, c'est que vraiment tu peux configurer exactement comme tu veux la machine,
tu peux aller très loin dans les réglages, optimiser au maximum, tu n'as aucune limite,
en fait la seule limite c'est tes compétences en fait en réglages et après voilà c'est vraiment
l'épidémie de la machine quoi mais sinon tu n'as aucune limite, c'est vraiment l'avantage.
Et souvent aussi ça peut être intéressant au niveau du coût parce que quand tu as des gros
projets, le fait de gérer toi même ta machine ça peut faire baisser les coûts au niveau de la
machine. Après ça n'empêche pas que tu auras des personnes en interne à payer pour gérer la
machine mais après c'est un équilibre à trouver mais pour les gros gros gros projets c'est souvent
un passage obligatoire pour baisser les coûts d'infrastructure. Ok, après on les connaît tous
les plus gros comme des exemples de services je pense qu'on connaît tous Amazon, Google,
console, plateforme et Azure, DigitalOcean qui existe aussi, Yauvh qu'on connaît tous parce qu'on
est français, peut-être qu'on connaît moins Scaleway, qui est français aussi c'est ça ?
Ouais, on connaît bien AWS, Google, Azure tout ça c'est vraiment les gros mastodons américains,
beaucoup à AWS, beaucoup de société qu'ils utilisent AWS mais Azure aussi tout ça est très présent.
OVH qui est très connu et depuis longtemps on propose des serveurs, voilà comme ça des
bar métal, tout ça que tu vas configurer et ensuite Scaleway qui est français, pareil,
qui propose des serveurs des virtuels machines, Scaleway c'est détenu par, comment ça s'appelle,
la société qui... Il y a des frites. Il y a donc c'est très, voilà ça appartient des français.
Donc c'est clair et non. Et après tu as aussi la plupart des ébergements souvent proposent du cloud,
du machine virtuelle, voilà disponibles. Je pense à Informadiaq qui est suisse, qui est basée à
Genève, voilà ils ont du public cloud et qui, voilà tu peux prendre une instance machine virtuelle et
puis tu installes ce que tu veux dessus. Donc il y a beaucoup d'offres à ce niveau là.
Ok, parfait. Et après, ok j'ai compris, je peux paramétrer ma machine tout,
mais si moi j'ai pas envie de paramétrer toutes ces machines là et moi je suis développeur back-end,
je fais du PHP par exemple et j'ai mon appli, je veux la déployer mais sans me prendre la tête
à gérer toutes ces machines là. Comment ça, ça tu vois c'est la, jusqu'à il n'y a pas très
longtemps on avait vraiment que la possibilité de prendre un serveur. Maintenant il y a des services
qui sont montés et qui sont vraiment pratiques parce que c'est vrai que quand tu as, en tant qu'indépendant,
fri-lanse, n'importe quoi, tu sais cool, tu veux monter ton serveur, machin, tu veux installer ton
node et tout, c'est sympa, mais au bout d'un moment, enfin, avant que ce soit ta passion,
tu n'as pas vraiment fait faire ça, ton coeur de métier c'est vraiment développer des applications.
Donc tu as envie que tu dépoilles le truc. Donc pour ça, il y a des passes qui sont montés,
qui sont disponibles, des plateformes à ce service et eux en fait ils te mettent à disposition
un conteneur. Donc tu vas créer un compte, tu crées un conteneur, tu choisis un techno,
donc ça peut être go, node, PHP, toutes les techno, tous les langages et derrière,
en fait, tu vas pouvoir mettre ton application qui tourne sur le langage dans ton conteneur
et dépoiller le content. Et là, ça fait tout en quelques clics et c'est souvent automatisé,
donc pas facile. Ok, et donc du coup, ça en fait ça va être vachement plus simple et donc il y a
moins cette barrière à l'entrée. Ah voilà, il y a quasiment zéro barrière,
c'est vraiment hyper simple. Et tout va se faire non pas en ligne de commande ou en fichier Yamel,
mais en interface graphique. En fait, tu as les deux, tu as souvent, le premier truc,
c'est que tu as souvent un dashboard où tu vas cliquer, déployer mon conteneur,
brancher mon beatup, mon repo pour qu'il aille chercher ton code, qu'il le mette dessus,
qui build ton application et qu'il la déploie. Ça, c'est souvent le dashboard. Après,
tu as des appellés qui sont disponibles, souvent des CLI qui sont disponibles que tu peux appeler
directement ton ordinateur pour lancer ou déployer des choses comme ça. Ça dépend des services,
il y a différentes offres, mais voilà, il y a suivant ce que tu préfères et c'est,
je te dis, c'est vraiment hyper simple en fait. Et la plupart du temps, c'est automatique. En fait,
tu vas brancher ton repo, il va déployer automatiquement. Si tu fais un commit,
il va s'apercevoir qu'il y a un commit et donc il va redéployer ton application avec le nouveau
commit, le changement. C'est tout automatique et t'as rien à faire. Donc, intégration continue,
déploiement continue et tout ça. Tout automatique, tout en quelques clics,
tout est hyper simple. Tu peux aussi, alors, on en parlera après, mais il y a souvent un peu
comme sur Vercel, tu vois. Sur Vercel, par exemple, quand tu fais une PR, une poulet request,
en fait, il va automatiquement déployer cette poulet request avec une URL dédiée et tu vas
pouvoir visualiser ton changement de code. Il y a certains services, des types Squalingo qui
proposent cette fonctionnalité qui fait que tu vas automatiquement déployer un nouveau container
avec cette poulet request, donc le code qui concerne la poulet request et tu vas pouvoir
visualiser si ton code y fonctionne. Tu vas pouvoir passer l'URL à ton chaîne de projet,
tout ça pour qu'il visualise, qu'il recette ton code, pour voir si c'est bon. Donc, ça,
c'est aussi un avantage que certains pass proposent qu'on n'avait jusqu'à maintenant que sur
des systèmes comme Vercel ou Netlify. Donc, c'est vraiment hyper pratique.
Ouais. Donc, Vercel ou Netlify qui sont des services purement back,
enfin, purement front, pardon, qui sont des purements front, et maintenant, ce type de
fonctionnalité arrive sur des outils pass pour le back. Et du coup, ce que je comprends,
c'est Squalingo qui fait ça ? C'est Squalingo qui fait ça, donc c'est une société française qui,
Basel Strasbourg, il me semble, avec un serveur à Paris. De ma connaissance,
c'est les seuls qui proposent ça. Après, je ne vais pas tester tous les services du monde,
mais j'ai regardé IR, Cleaver Cloud, qui, si ça le proposait, parce que Cleaver Cloud,
je ne connais pas bien la plateforme, j'ai déployé un site IR pour tester. J'ai regardé
si il y avait un système de PR et apparemment, pour l'instant, ce n'est pas disponible.
Donc, j'espère que ça viendra par la suite parce que c'est quand même super pratique pour
une équipe de devre. C'est le temps que Cleaver Cloud, c'est quand même un bon service,
donc service français, Cleaver Cloud, qui a des serveurs un petit peu partout dans le monde,
mais c'est quand même un service qui est en France. Société française. Très important.
Par rapport à la privacy, puisqu'on a parlé dans le dernier épisode par rapport à les informations
qui transitent aux US, etc. Là, on est vraiment sur les sociétés françaises, donc il n'y a aucun
risque que les US viennent sur ton serveur, prendre des infos et repartir une vie unicognite.
Ok, top. Et ce type de service, ça gère la charge pour moi. C'est-à-dire si demain,
je me fais, on connaît tous l'histoire d'une startup qui passe sur M6 ou sur FETL,
quoi. Tout le monde se connecte sur le site. Le site est sur un WordPress mutualisé. Il
est le truc qui ne tient pas la charge. Ça s'écroule. Et donc, du coup, est-ce que ce type
de service-là gère la charge à la hausse et à la baisse ?
Ouais, on appelle ça de l'auto-squale. En fait, tu vas définir. Alors, ce n'est pas
automatique ça, il faut le définir. Que ce soit sur clé for cloud ou squalingo. Après,
les autres, ça doit être disponible aussi, je pense, sur Heroku, ça doit être disponible.
En fait, tu as un conteneur ou deux par défaut de la taille que tu as définie. Et en fait,
tu vas lui dire si ça augmente le trafic, tu vas te laisser, tu as le droit d'aller jusqu'à 3,
4, 5 conteneurs. Donc lui, automatiquement, il va augmenter le nombre de conteneurs pour
baisser la charge et répartir sur tous les conteneurs. Et donc, si jamais tu as un passage à la télé,
que tu as beaucoup de trafic d'un coup, pas de problème, il va augmenter les conteneurs et
l'application va toujours répondre sans problème. Et ensuite, après, dès que la charge de trafic
va baisser, il va diminuer les conteneurs et revenir à ton nombre de conteneurs par défaut.
Ok, top.
Ça, c'est hyper pratique.
Ok, ça, c'est top. Du coup, c'est adapté pour les personnes, on va dire, frilances qui veulent
pas gérer les machines, le bloc de leur carrière de métier, c'est vraiment du dev et c'est pas
géré une infra. C'est adapté aussi pour peut-être des équipes qui n'ont pas de personnes dédiées.
Ouais, c'est ça. Ça va adapter à tout ce que tu dis, indépendants, petit équipe, start-up ou
société qui n'ont pas envie de gérer l'infra. Simplement, qui préfère passer par des services
comme ça, qui sont peut-être un peu plus chers que de prendre du serveur brut, comme on a dit au
début, des machines virtuelles. Parce qu'il y a forcément un service, c'est une sur couche autour
et c'est peut-être un petit peu plus cher, mais tu enlèves toute la gestion, le paiement d'un
service. Mais s'il faut payer un mec avec des compétences spécifiques que pour faire ça, peut-être
que c'est beaucoup plus rentable de mettre la carte bleue et il gère ça pour moi. C'est beaucoup
plus rentable et surtout tes devs sont... Imaginons, tu as une société avec un service de
développement, tes devs sont autonomes, ils ont un compte, ils déploient, ils règle le truc comme
ils veulent et il n'y a pas besoin d'être hyper compétence, une interface. Non, c'est vraiment
super intéressant pour plein de cas de figure et comme je te disais au début, après ça dépend
si ton projet prend une ampleur vraiment énorme. Peut-être qu'à un moment donné, il va peut-être
mieux passer sur un serveur dédié avec une équipe qui s'en occupe parce que forcément il y a une
histoire de coups parce que là on parle après de centaines de milliers d'euros de coûts de serveur,
mais quand on est sur un projet plus classique, un passe peut très bien faire l'affaire et ça
t'enlève tous les soucis de gestion, d'infra, l'auto-squade, tu veux dire que le week-end
t'es tranquille, tu sais que ton serveur se squade tout seul, pas de problème, tu sais que le serveur
ne tombera jamais. Yes, carrément, du coup il y a Eroku qui est dans la place depuis très longtemps
là-dessus, qui est vraiment ce créneau là, qui facilite tout ça. Il y a Scalingo qu'on a dit,
auto-clever-cloud, il y en a d'autres aussi ? Fly.io, tu as Render.com, on a Gélastik qui propose,
alors Gélastik c'est une interface, alors E c'est une société qui fait une interface pour
gérer justement ce système de machine virtuelle avec des sortes de sliders qui va définir combien tu
veux d'instances, et tout ça. Et c'est une interface que tu peux retrouver chez Infomaniac,
par exemple, si tu prends un cloud. En fait, E, il fournissent une interface graphique que tu
vas mettre en surcouche de ta machine, comme si tu gérais un... Parfois, tu as un compte, tu vas
dessus, là, sur l'interface qu'on voit un petit peu sur le site, et puis tu vas régler ton truc comme
tu veux, et tu as un coût en fonction de ce que tu vas régler, tout ça. Donc, c'est...
Ok, excellent. Il y a aussi Render qui est sur le même créneau, pareil avec des provisions de
machine, et pour le coup, ils vont mettre aussi comme tous les autres, mais des bases de données,
ou des choses comme ça, ou en trois clics, on va ajouter... Ouais, tu as souvent des bases de données
qui sont liées aux émergements. Tu as un conteneur applicatif qui va faire... Alors, c'est vraiment
hyper varié en termes de langage. Tu retrouves souvent tous les langages un petit peu utilisés...
Tous les frameworks classiques, quoi. Ça peut être, jusqu'aux frameworks, parce que tu as même
certains services qui détectent automatiquement les... Par exemple, tu utilises Next, il y a
commande pour lancer le build, commande pour déployer tout ça, pour starter. Après, tu as
vraiment d'autres langages, du coup, vraiment, c'est hyper... Il y a vraiment beaucoup de disponibilité,
et souvent, tu as une base de données disponible avec toi, qui est payée en dossier, à part.
Bien sûr, par contre, ça vient faire la connexion automatique entre mon appli et ma base de données.
Alors ça, je n'ai jamais essayé, parce que j'ai jamais pris de base avec, je t'avoue. Mais j'imagine
que oui, ça va être facile de se connecter. En fait, sur AeroCOO, ça marche vraiment bien.
Ce qui s'appelle des add-ons, en fait, où tu viens mettre du redis, du post-gray,
tout ça, et tu viens créer des add-ons, et ils te donnent les variés d'environnement.
C'est ça, oui. Sur AeroCOO, tu as un fichier YAML, que tu peux régler avec tes... Je ne sais plus comment ça marche.
En fait, tu peux tout régler en mode config, ou après, depuis ta CELI, tu fais tout le système.
Après, je pense que tous les acteurs sont à peu près basés sur le même système.
Oui, ça dépend. Moi, je connais bien Squalling Go, parce que je l'ai utilisé,
depuis ces derniers mois. Ils ont un gros avantage, c'est qu'ils ont... Je fais de la pub,
mais je ne suis pas rémunéré, malheureusement. Mais ils ont un gros avantage, c'est qu'ils ont un service...
Comme c'est français, ils ont un service, c'est un chat dans l'interface quand tu as un compte,
et ils te répondent très rapidement. En fait, c'est d'ailleurs ce qu'ils mettent en avant souvent,
c'est qu'ils ont un service client qui est hyper rapide. Dans 15h, tu as une réponse.
C'est hyper bien fait. Pareil, j'ai testé Clover Cloud hier, puisque je testais pour voir
s'il y avait un déploiement automatique d'EPR. J'ai parlé dans le chat sur l'interface,
et j'ai eu la réponse dans les 20 minutes. C'est plutôt pas mal. C'est pour ça que souvent,
moi, je pousse les services français, parce que c'est important d'avoir des réponses quand
tu es bloqué sur un déploiement ou pour faire marcher tel techno.
Super. Super client. Super client qui est intégré dans le service. Pas en plus payant.
Certains américains font payer le service client à prix fort. Je peux même raconter une histoire.
Je ne sais pas si je peux te la raconter sur Vercel. Je ne crache pas sur Vercel.
Vercel est un super service et je continuerai à l'utiliser. Ce qui nous est arrivé dernièrement
avec un client, c'est qu'on avait choisi, on a développé une application sur du Next.js.
Donc, logiquement, on a déployé sur Vercel. Cette application fait partie d'un site et on avait
un proxy qui renvoyait l'URL qui correspondait à cette application sur Vercel. Tout se passait
bien depuis plusieurs mois. Nickel. L'application fonctionnait très bien. Les développeurs qui
ne connaissaient pas Vercel ont adoré Vercel. Ils adoraient ce système de déploiement automatique
pour le request, pour pouvoir visualiser, pour pouvoir... Vraiment hyper simplement. L'expérience
développeur est top dans ces services-là. Ce qui s'est passé du jour au lendemain, notre proxy,
notre serveur proxy qui renvoyait sur l'application Vercel a été bloqué. On ne sait toujours pas pourquoi.
En fait, du jour au lendemain, le site n'a plus marché. L'application n'a plus marché. Vercel ne
répondait plus du tout à l'URL. C'est là où on a connu en quelque sorte la faiblesse de ces services.
C'est qu'en fait aujourd'hui, ça fait quand même plus de deux mois, aujourd'hui on ne sait toujours
pas ce qui s'est passé puisque le service client n'est pas capable de nous répondre.
Est-ce que le service client a répondu ou le service client ne peut pas répondre parce que
eux-mêmes ne savent pas ? En fait, c'était très long d'avoir des réponses. On en voyait par email,
etc. Tu les contacts, ils te répondent des fois à côté, tu renvoies un email,
donc il se passe une semaine. Pendant ce temps-là, ton site est EUR-LINE. Il faut le voir comme ça.
Donc toi, tu es hyper pressé que ce soit en ligne. Là, tu ne comprends pas. Il y a un problème
quand le service client, et en fait jusqu'à aujourd'hui, ils n'ont jamais été capables de le dire.
Nous, on soupçonne qu'ils n'étaient pas capables de savoir pourquoi le proxy a été bloqué,
puisqu'en fait derrière Vercel, c'est de la WS. Donc des fois, il y a des trucs un petit peu
obscur. On ne sait pas vraiment. Ce qui fait qu'à un moment donné, nous, on a migré sur
Netlify. On s'est dit, on va tester sur Netlify, puisque Netlify prend en charge une X.js. On s'est
dit, on va essayer de voir pour un forfait sur Netlify ou Vercel, tu as un forfait assistance
en fait que tu peux payer pour les entreprises qui te permet de avoir des réponses plus rapidement,
d'être en prioritaire, etc. Et donc on a demandé un devis puisque sur le site Netlify,
tu n'as pas de prix, tu vois, tu contacter nous, entreprise. Pour la version ultime,
pour la version entreprise avec... Je ne sais plus si tu avais dit le prix à l'époque,
mais tiens toi bien, tenez-vous bien. En fait, le premier niveau d'assistance pour les entreprises,
en fait, il est à 3 000 euros par mois. Donc on s'est dit, ok, en fait, c'est pas possible,
on ne va pas payer 3 000 euros, enfin, l'entreprise ne peut pas payer 3 000 euros juste pour avoir
de l'assistance, etc. Donc en ce moment-là, on s'est mis en quête. Donc là, tu te rends compte
quand même que les services US, à un moment donné, il y a les limites, tu vois, et qu'à un moment,
il faut les payer, quoi. C'est le prix foire. Et donc à partir de là, on s'est mis à la recherche
d'un autre service qui serait compatible avec Netlify. Et c'est là où on est arrivé sur
Voilà. Et vous êtes retournés en fait chez les Français, quoi ?
En fait, la priorité, si tu veux, à partir de ce moment-là, pour le client,
en fait, la priorité, c'était d'avoir du service client. Bien sûr.
Que si jamais, ne remarchez pas, qui est quelqu'un pour répondre. Et en fait,
Squalingo a répondu à cette problématique, puisque c'est vraiment la chose qui met en avant,
c'est que le service client, il répond rapidement. Donc ça ratio avec client,
et on est passé sur Squalingo, et Next.js marche très bien sur Squalingo.
Excellent. Bon à savoir. Bon à savoir. Top. Top. Petit retour d'expérience,
toujours intéressant. Oui, intéressant. On pousse beaucoup les systèmes
comme Vercel, tout ça, parce qu'il y a des offres qui sont soit gratuites, soit pas très cher.
Mais c'est vrai que quand tu as vraiment un problème et que c'est une société qui,
voilà, qui d'un coup, tu as pu le site en ligne et tu perds de l'argent, il y a une urgence.
Et il faut avoir quelqu'un qui répond derrière. Bien sûr. Bien sûr. Dans nos recherches,
pour le coup, on n'a pas testé, mais on a trouvé Qlify, qui en fait est un peu le mix entre
les deux solutions qu'on a présentées, c'est-à-dire vraiment la gestion de la machine
brute et la plateforme As-de-Service. En fait, Qlify, c'est, on va installer ça directement
sur la machine et ça va créer une interface où on va pouvoir justement administrer
nos applis et en fait, on vient hoster nous-mêmes notre propre plateforme qui va orchestrer et
déployer toutes nos applications. Du coup, ça met une surcouche. C'est un peu la croisée entre
les deux mondes, entre la plateforme As-de-Service et la pure machine. En fait, là, on vient acheter
notre machine et on met Qlify dessus et c'est comme si on pouvait…
C'est pas mal. Je sais pas si…
Ouais, après, sur le papier, c'est pas mal. Après, objectifement, enfin, je n'ai pas testé,
donc je ne sais pas du tout ce que ça dit, mais en tout cas, sur le papier, c'est plutôt pas mal.
C'est facile à installer, tu crois ? Enfin, j'ai…
Bah ouais, moi, j'ai vu une vidéo d'un mec, il se connecte à sa machine en SSH,
il tape la ligne de commande qu'on voit à l'écran. Pour ceux qui ne suivent pas sur YouTube,
vous pouvez nous retrouver sur YouTube. En fait, il y a une commande et on tape cette
commande et ça lance la machine et c'est parti. Ça nous crée une interface admine et tout ça et
on se connecte directement sur l'IP de notre machine et puis c'est parti. Après, on a accès à une
interface. Du coup, il faudrait tester avant d'en dire du bien ou du mal. Mais en tout cas,
sur le papier, c'est plutôt pas mal parce qu'on va pouvoir déployer des applis front, des applis
back, des database, on va pouvoir monter directement depuis GitHub, GitLab et GitBucket.
On va… ça déploie les pool requests sur des URL spécifiques. On peut gérer les droits avec
« Faire venir du monde » en mode « équipe ».
Ça a l'air super complet en fait. Ça doit être basé sur le docker parce que l'application,
tu vois, il n'y a pas de limite, c'est un peu tous les langages.
Du coup, c'est impressionnant. Je pense que c'est un truc à aller suivre un petit peu. Evidemment,
ils sont sur Product Hunt. Donc voilà, à suivre et surtout tester pour voir ce qui commence à
marche. Après, il y a même des services directement pour mettre du WordPress, du Ghost ou des
plausible analytics ou des choses comme ça où là, il y a un déploiement en un clic.
C'est le meilleur des demandes. Tu prends ton serveur et puis tu installes ça dessus et ça
se fait tout automatiquement. En plus, c'est sur le papier. Après, ça s'installe avec un WGate.
Ça a l'air magique en fait. Ça a l'air plutôt pas mal.
Du coup, on arrive à notre troisième partie où en fait, on a une autre typologie de services
qui vont s'offrir à nous. C'est les basses. C'est une catégorie que tu connais mieux que moi,
back-end as a service. C'est un truc que tu utilises pas mal pendant tes projets. Je
sais. C'est moi qui vais te poser des questions cette fois. Alors, comment ça fonctionne un bass ?
En fait, back-end as a service, c'est clairement, je vais automatiser un maximum de choses et je
vais déléguer ça à un service dédié. Un exemple typique, quand on fait une appli,
souvent, on va gérer des crudes une fois, deux fois, trois fois, quatre fois sur différents modèles.
Clairement, à la fin, il y a assez peu de valeur ajoutée à optimiser ton crud une fois,
deux fois, trois fois, quatre fois. En fait, on fait tout le temps la même chose. Donc ça,
c'est déjà hyper chronophage et au final, ça amène peu de valeur ajoutée de le faire soi-même.
Donc l'idée, en fait, c'est de dire, ok, moi, je n'ai pas envie de gérer une machine.
Je n'ai pas envie de coder même, de coder encore un crud et encore un crud. C'est super chiant.
Du coup, je vais déclare, je vais configurer via une interface graphique dans ce type de
service-là et je vais déclarer tous mes modèles et ça va me faire une API directement que je vais
pouvoir utiliser via le langage que je souhaite. Donc souvent, beaucoup vont être des clients
GS, mais on va avoir des clients Flutter, des clients PHP, des clients Ruby, on va avoir
pour différents langages. Mais en fait, on va vraiment automatiser et structurer déléguer
un service toute la création de notre backend, d'où son nom, backend as a service. Là,
on va avoir différents acteurs. Je pense que le plus ancien, c'est Firebase qui est un des
plus connus. Le gros avantage, c'est qu'on va être hyper productif. On va tout de suite pouvoir
déployer une solution très rapidement. L'avantage aussi, c'est que notre API,
ou l'API qui va être généré par ce type de service-là, va être optimisé nativement parce
qu'il y a déjà plein de personnes qui ont bossé sur l'optimisation de ce service-là.
Donc en clair, l'API va être monstre rapide et super optimisé.
Là, on parle de backend, mais c'est principalement pour créer des services API avec des bases
de données, des crottes qui vont répondre, qui vont pouvoir insérer, appeler, etc. Mais
c'est vraiment en parlant de création d'API en gros.
Oui, absolument. Ça va vraiment gérer les API directs. Soit tu veux utiliser le mode client,
ou j'ai un client JS par exemple, j'avais script qui va pouvoir appeler mes modèles avec les champs,
je vais pouvoir les créer, les updates, etc. Ou je vais directement avoir un endpoint. Je pense,
par exemple, à des générations d'API sur GraphQL. En fait, je vais déclarer mes modèles et j'ai
une API GraphQL qui va être automatiquement mis à jour et autogénérée. Je vous renvoie à l'épisode sur
Asura, justement, où on parle de ça. Mais dans l'idée, c'est de déléguer toute cette création
et de côté automatique. Mais ça ne fait pas que ça. Parce que là, on vient juste créer un backend,
on va dire, nos contrôleurs sur un modèle MVC, on vient créer le M du modèle, le contrôleur et le
endpoint. Très bien. Par contre, le gros avantage qu'il y a encore par dessus, c'est que ça va
aussi gérer l'authentification pour nous. Parce que la plupart du temps dans les applis modernes,
c'est login password. Et donc login password, où je veux me faire un connect via Facebook ou via
Google, via GitHub. En fait, ce système d'authentification, une fois de plus, pour une appli,
pour deux applis, pour trois applis, pour quatre applis, c'est tout le temps la même chose. Du coup,
le coder à la main, ça n'apporte rien. Ça mène très peu de valeur à ajouter. D'autant plus que
sur l'authentification, quand on parlait de sécurité tout à l'heure, l'authentification,
en fait, ça peut être hyper critique. Parce que s'il y a une faille de sécurité qui a été
mis en place ou découverte sur une techno, sur une libre qu'on a utilisée, si nous,
on n'a pas fait la mise à jour ou des choses comme ça, on peut être exposé. Alors que ces services-là,
ok, on les paye. Mais eux, ils vont gérer tout ça pour nous. Et donc l'authentification,
elle va être bêtant, elle va être super organisée.
Oui, ça va bien voir rapidement, ne pas te chez aussi un problème.
Exactement. Et en fait, quand on voit des solutions type soupabays,
pour le coup, ils vont gérer toute la base de données, les API. Donc on va pouvoir
interagir avec la base de données toute l'authentification. Donc login, password,
évidemment aussi les droits. Parce qu'en fait, on va gérer qui a accès à quoi. Et une troisième
partie qui va être intéressante, ça va être la gestion du storage. Par exemple, dans mon
appui, je veux que les utilisateurs puissent sauvegarder des images. Et ces images-là,
il va falloir que je les stocke. Donc soit si je le fais en mode machine pure, ça va être avec
du Amazon S3 ou l'équivalent. Mais il va falloir que j'arrête, interagir, créer,
configurer. Là, en fait, j'ai un accès immédiat à du storage et ce de manière hyper facile
et transparente. Souvent, ils ont fait un client basique. Là, je vais regarder sur soupabays.
Je vais avoir un client JavaScript, un client flutter. Je vais pouvoir interagir directement.
Tu vas l'intégrer dans ton code et puis tu vas envoyer les images, tu essaies d'imager.
Exactement.
Tu vas appeler la base. Alors, qu'est-ce que les avantages, on a déjà donné pas mal.
Mais si on peut résumer les avantages du base.
Alors, les gros avantages, c'est quand même qu'on n'a pas du tout à gérer l'infra,
ni le déploiement, ni l'autoscale. Voilà. Là-dessus, c'est vraiment délégué totalement.
Voilà.
En fait, tu ne gères même pas de conteneurs. Toi, tu as fait le service et ça répond.
Exactement.
C'est pas à toi de dire.
C'est vraiment full web. Un autre avantage, mine de rien, c'est que la plupart de ces services-là,
ont un ticket d'entrée au départ sur le pricing où ils ont tous des offres fries au départ.
Donc, en fait, ils vont nous donner. Là, on est sur Superbase, par exemple. On a le droit à deux
projets gratuits avec une base de données de 500 MHz et 1 Giga de storage et on va limiter en bandes
passantes. Mais toute l'authentification, les appels de fonctions serverless qu'on va parler après.
Mais tous ces services-là, pour la plupart, ont une offre frie au départ. Donc, c'est facile.
Et justement, ils ont fait ça en termes de marketing.
D'un bout au truc et après, c'est la première dose, en gros.
Exactement, c'est la première dose. Mais d'un autre côté, c'est aussi super frie.
Enfin, c'est faire. En tout cas, moi, je trouve ça assez bien parce que si ton projet,
il a demande d'explose, c'est que tu as plutôt un bon problème. Donc, tu as des clients qui vont
payer ou pas. Mais en tout cas, tu vas payer au fur et à mesure que tu vas consommer. Et donc,
tantiqués d'entrée au départ, il est plutôt faible. Donc, ça, c'est plutôt une version pro.
Enfin, si c'est pas belle, je vois version pro, 25 $ par mois. Ça reste très raisonnable.
Avec une base de données de 8 Giga, avant d'avoir 8 Giga de données, c'est déjà pas mal.
Il y a 100 Giga de storage, 2 millions d'invancations de fonctions.
Tu peux y aller. Ton service, c'est que tu marques déjà. Si tu arrives à appeler 2 millions de fonctions.
Après, justement, c'est là où on vient de toucher un peu la limite.
Les inconvénients, c'est que ce n'est pas toujours open source. Donc, ça peut être un peu une boîte
noire type Firebase qui a été racheté par Google il y a très longtemps déjà. Donc,
ça marche super bien. Par contre, le choix de technologies sur la base de données,
c'est d'une OSQL. Donc, cette approche, ça peut convenir sur certains projets.
Parfois, ce n'est pas du tout adapté. Parfois, ce n'est plus compliqué. Voilà,
c'est un choix. Par contre, on ne sait pas du tout ce que... Enfin, ça reste Google.
D'où l'apparition de Superbase, où justement, ils se mettent vraiment en mode frontal direct,
parce qu'ils disent que c'est une alternative open source à Firebase.
Ils sont pour sourcils à base complètement. Tu peux aller voir les codes sur GitHub.
Exactement. Tu peux le self-hoster chez toi. Par contre, c'est toi qui va gérer ta machine.
Soit, tu utilises leur version cloud et là, tu payes ou pas. Donc, ça, c'est plutôt cool.
Après, alors là, je vais faire la promo, mais moi, je suis clairement convaincu.
Je trouve ça trop trop bien de nost. nost, en fait, pour boucler sur là où on avait laissé avec
Asura justement. En fait, ils viennent utiliser la partie de Asura pour toute la partie back-end,
crue de génération d'API. Ils viennent mettre l'authentification et le file storage
directement pour simplifier tout ça. C'est un produit que je teste en ce moment.
Je trouve ça trop trop bien et vraiment super rapide. Après, il peut y avoir une barrière à
l'entrée parce que la barrière à l'entrée, c'est sur la gestion de Asura. Par contre, sur la
gestion des users et de l'authentification, ils ont un client JS qui marche super bien.
C'est hyper intuitif. C'est un soft-couch.
Exactement.
Tu dois gérer Asura comme tu le gères d'habitude et tu as n-host en plus.
Exactement.
Là, pour le coup, sur le client JavaScript, je vais avoir toute l'authentification avec
toutes les méthodes sign-up pour avoir le token JWT avec tous les droits qu'il y a à l'intérieur.
Tu vas avoir le storage pour aller récupérer tout tes fichiers ou uploader tes fichiers.
Tu vas avoir des fonctions à ce service et ton API GraphQL classique qui va être géré par
Asura. Et quelque chose qu'on n'a pas dit sur tous ces services-là parce que le backend, on dit
OK, c'est bien. Mais toute ma business logic, elle est spécifique. Je la mets souvent dans
des serverless functions. C'est vraiment des fonctions qui vont être envoyées et déployées
pour vraiment exécuter la logique métier. Et donc, tous ces services-là viennent provisionner
justement des fonctions à ce service pour exécuter toute la partie business-métier.
Je voulais juste faire une appartée pour les gens qui ne sont pas trop au fait de ce que c'est
une fonction serverless. En fait, c'est une fonction qui tourne uniquement quand on l'appelle.
Elle est sur un serveur, on appelle une URL, cette fonction exécute ce qu'elle doit faire.
Elle renvoie une réponse et ça s'arrête. En gros, c'est ça une fonction serverless.
Donc, ça veut dire que c'est du serveurless, mais il y a un serveur.
Mais il y a quand même un serveur, le mot n'est pas très logique. En gros, c'est une fonction
qui est toute seule, qui traîne sur un serveur AWS quelque part dans le monde qui est appelé
un point et qui exécute au moment où l'on l'appelle. C'est pour ça qu'on parle de
fonction serverless. Elle est attachée à aucun serveur.
Et un autre service qui marche aussi, c'est Apprite qui peut être self-hosté aussi,
mais utilisé en mode cloud.
Je reviens sur Enos qui peut être self-hosté aussi.
Oui, absolument.
Et Open Source aussi, pareil.
Oui, totalement Open Source. C'est vraiment dans leur ADN.
D'accord. Et suite à Enos.
Exactement. C'est une compagnie suédoise qui est assez récente, qui a bien grossi et qui
est en pleine expansion. J'ai testé quand c'était en V1. J'étais pas totalement convaincu.
Là, ils ont fait une levée de fonds. Ils sont passés à la V2. Ils sont encore en beta, mais
enfin, voilà, c'est déjà beaucoup plus solide, beaucoup plus structuré. Donc, c'est top. C'est
vraiment top. Et un autre aussi, AWS, toujours sur le même concept où on va avoir une interface
graphique pour vraiment construire notre application. Ça va créer des modèles. Alors,
tendance ou pas, beaucoup font du GraphQL. D'autres vont avoir des endpoints où ils vont
avoir un client directement JS pour interagir avec tout ça. Mais en tout cas, il y a quand même pas
mal de solutions qui nous permettent de faire des back-ends hyper rapidement. Alors, plein de
gens vont pas aimer parce que c'est trop magique. Et donc, justement, dans les inconvénients,
j'ai voulu voir que tu avais marqué à qui à partir les données. C'est toujours là la question.
Est-ce que leur propre infrastructure est basée où ? Est-ce que eux, ils sont responsables ?
Enfin, voilà, plus on vient mettre d'intermédiaire et de couches avec la machine,
et bien chaque partie va prendre ses responsabilités ou pas, selon les conditions
générales. Et du coup, c'est à nous d'aller creuser à chaque sur-couche qu'on installe,
de voir qui est responsable et qui détient, qu'est-ce qu'ils peuvent faire des données.
C'est souvent sur-couche AWS en plus. Tu pars du temps, c'est l'équipe qui vit à AWS.
Oui, parce qu'en même temps, qui peut fournir des infrastructures à la volée comme ça en trois
clics à part les gros. Et après, si je prends l'exemple d'AWS, je sais que c'est compliqué,
tu as des cités sur AWS, tu as des choses qui sont vraiment liées à AWS, tu as du mal à
migrer, si tu vas aller sur Google, par exemple, sur Azure, il y a vraiment des systèmes qui sont
spécifiques à chaque host. Est-ce que là, par exemple, c'est facile de migrer de Superbase
à un host ? Est-ce que les fonctions fonctionnent de la même chose ? Ou c'est vraiment compliqué de
changer de système ? En fait, de toute façon, chaque client va avoir sa terminologie. Par exemple,
sur Superbase, la façon dont tu vas appeler tes modèles et tes champs vont changer. Si vraiment,
tu veux te détacher de Superbase, l'avantage, c'est que ta base de données est détachée.
Ta base de données, elle est en poste gré. Si tu veux le migrer vers un autre service,
ça risque peut-être compliqué, quoique à limite, ta source de vérité, ça va être ta base de
données. Tu supprimes ton service et tu replugues ta base de données sur un autre service et tu
recrées ton API sur comment tu vas requêter toutes tes données. Dans ce cas-là, oui, tu peux le
faire, mais n'oublions pas que la source de vérité va être sur ta base de données. La
manière dont tu vas appeler les choses, ça va être propre à ton client.
C'est quand même quelque chose à réfléchir avant de s'engager sur un projet, sur un service.
En fait, je pense qu'avant de partir sur des services comme ça, il faut bien comprendre les
limites du projet pour savoir jusqu'à où on va pouvoir aller avec ce type de service-là.
C'est-à-dire que peut-être qu'au départ, ça va être super bien pour faire un POC ou une
Proof of Concept ou un MVP, une version 1. On teste le produit, on voit qu'il y a une traction,
on peut passer sur une V2 et là, dans la V2, on passera sur une autre technologie. Par contre,
le gros avantage que je vois, c'est la vitesse avec laquelle on peut déployer ce type de solution.
Si on sait que le projet est de toute façon voué à ne pas exploser parce que ça restera dans un
petit giron, peut-être que ce type de service-là peut largement suffire et donc on n'aura pas besoin
de faire des migrations de technologie parce que le projet, par définition, il est déjà limité.
En fait, je pense que si on essaye un peu de prendre un tout petit peu plus de distance et de recul par
rapport à tout ce qu'on vient de dire depuis le début de l'émission, je pense qu'il n'y a pas de
bonne technologie ou de mauvaise technologie. Mais je pense qu'il faut bien comprendre le scope et le
périmètre du projet pour choisir la bonne technologie mais aussi l'équipe. Parce que si on
fasse, on n'a pas les bonnes personnes pour utiliser les bonnes technos, ça ne va pas faire. On dit souvent
que la bonne technos, c'est celle qu'on maîtrise et je pense que c'est super important. Pareil sur
l'hébergement ou sur la mise en place de baccaines automatisées sur des basses, si justement,
ce n'est pas bien calibré, on est sûr de se planter. Je vois que ça correspond vraiment à une
petite équipe avec des devs front qui sont capables de développer une API avec des outils comme ça.
C'est vraiment bien, c'est pratique, efficace. Bon produit.
Carrément, après il faut tester pour si des devs veulent se lancer sur des side projects ou pour tester
et tout, c'est fait pour ça. C'est extraordinaire. Convénque à 100%.
Oui, mais clairement. Après, je suis dans une configuration où je suis tout seul. Si je gère
mon client qui est souvent petit, je vais m'appuyer là-dessus et ça va être vachement pratique. Pour
avoir intégré des petites équipes où il y a deux, trois, quatre devs où ils gèrent toutes leurs
infrastructures sur Azure, ça leur coûte les yeux de la tête et tous les devs transpirent pour rentrer
dans la doc et personne ne veut rien toucher parce que c'est en place et personne ne veut rien toucher
et ça coûte super cher à la boîte. Et en fait, c'est un frein à la productivité, c'est un frein
à l'épanouissement des devs parce que les gars doivent se palucher la doc de Azure et de savoir
comment ça marche. C'est hyper compliqué. En fait, ils perdent en agilité sur le développement
de features pour faire évoluer le produit. En fait, je pense qu'il faut vraiment bien
calibrer le projet et trouver le bon outil pour déployer notre application avec le bon outil
selon la taille de l'équipe, la taille du projet. Et ça, c'est des choix qu'on fait en an au départ.
Et si les mauvais choix sont faits, ça coûte cher, ça coûte très très cher en 30 ans.
Ok, donc on passe à la dernière catégorie. Yep, des services de hosting. On a appelé ça
les serverless pass. C'est un peu comme ça que ça s'appelle, je pense. C'est comme des passes,
sa mode fonctionne en mode serverless. Donc là-dedans, c'est tout ce qui est
versel, Netlify, Stormkit, je cite déjà les services qui existent qu'on a listés. Donc en
gros, c'est un peu comme les conteneurs. Tu déploies ton application, sauf que derrière,
ce n'est pas un conteneur que tu vas gérer. C'est le service qui gère lui-même des fonctions
serverless qui sont souvent sur AWS. Et voilà, c'est pour ça que ça fait un pass serverless.
Ok, et donc du coup, ça, c'est versel, parce qu'en fait, versel et Netlify qu'on connaît
beaucoup, ou Claude Flair, à la base, en fait, c'est plutôt des hébergeurs frontes en fait.
Ouais, c'est principalement. Alors oui, à la base, c'était vraiment Netlify, c'était clairement
un hébergeur front qui faisait plutôt même du statique à la base. Vraiment, il y avait très peu,
ces dernières moments qu'ils ont rajouté toutes les fonctions serverless et tout ce qui est,
ils sont adaptés aussi pour faire fonctionner le Next.js qui fonctionne aussi maintenant avec un mode
hybride, avec régénération des pages, etc. Ce qui n'était pas nécessaire quand ils déployaient
que du statique. Versel a toujours fait quand même du backend, en fait, avec des serverless.
Depuis toujours, ils avaient déjà, dès le début sur Next.js, c'était déjà du
server-side-renoring, donc il y avait quand même d'une note qui tournait derrière.
Versel a toujours fait du serverless. Mais ouais, ils se sont adaptés au fur et à mesure.
Alors c'est marrant parce que c'est des services qui ont tendance à plutôt s'adapter au framework,
à l'évolution des frameworks, au fur et à mesure qu'il y a des nouvelles fonctionnalités qui
changent, qui évoluent. Et comme je disais, depuis Netlify, ils ont tendance aussi à suivre.
Ils ont fait des gros efforts pour adapter Next.js pour que ça tourne sur Netlify.
Quand tu déploies un Next.js sur Netlify, ça va te déployer plein de fonctions,
tout ça, qui vont pouvoir te faire tout ce service, note qui tourne derrière en server-side-renoring.
Il n'y a pas de mystère, mais je suis très vu et très nuckst. La version 3 va bientôt sortir,
ils sont en RC2 maintenant. En fait, toute la partie server se fait avec 0 configuration.
On déploie sur Netlify qui a la base un rendu client et toutes les parties serveurs vont être
automontées et vont être interprétées en fonction à ce service. Et ça, sans aucune configuration.
C'est ouf. C'est là où tu vois le travail que ces sociétés font derrière.
Ils adaptent la plateforme au framework comme Next.
Ils ont un système qui est complètement changé, ils ont adapté, ils proposent une nouveauté verselle.
La vraie question, c'est les plateformes qui font évoluer les frameworks ou les frameworks
qui font évoluer les plateformes ? Est-ce qu'il n'y a pas un cercle vertueux où les deux se tirent
et pas se tirer la bourre, mais offrent des services ? Si la plateforme a un déploiement hyper
facile pour un framework particulier, les gens qui utilisent ce framework vont plutôt s'orienter
vers cette plateforme-là. Et inversement, si le framework est super facile à déployer,
si tu veux, c'est un cercle vertueux pour les deux, non ?
Pour moi, c'est vraiment la plateforme qui s'adapte au framework.
On le voit au fur et à mesure que les frameworks évoluent. On voit les nouvelles features qui
arrivent sur les services à chaque fois. Dès que tu as une évolution du framework,
Pam rajoute des fonctionnalités, un coup d'annonce, d'email, pour dire « on prend ça en charge,
on prend ça en charge ». C'est vraiment les plateformes qui évoluent au fur et à mesure que
les frameworks évoluent. Ce qui est sûr à certains.
Ils suivent les tendances. On voit aussi l'évolution de la gem stack.
On utilise encore ce terme, mais il est temps à disparaître. On voit l'évolution de la gem stack
qui part sur le site statique du serveur Cyrendring, et on voit donc les plateformes qui fur et à
mesure proposent des fonctions Edge qui sont disponibles sur Netlify.
Après, sur tous ces modes de rendu spécifiques, c'est vrai que parfois on s'y perd un peu.
À la limite, on fera un épisode où on prendra un peu le temps de venir expliquer
le client-side, la réhydratation, l'H-computing, tout ça.
C'est des termes un peu barbares. Il y a beaucoup d'acronyme,
mais il faut comprendre la technologie derrière et comme ça, on peut voir à quoi ça sert et
comment c'est structuré. En plus, tu parles de plateformes qui s'adaptent au framework.
J'ai eu le cas, comme je parlais de tout à l'heure, comme j'ai cherché un hébergement
dans une Edge JS. C'est là où je me suis rendu compte que la JS ne tue pas forcément les berges
partout. Par exemple, j'ai essayé sur Amazon AWS Amplify. C'est un service qui permet un peu
à l'averselle de déployer une application facilement avec une interface qui est plutôt facile à comprendre.
Pour le coup, il ne prenait pas une Next JS version 12. Il ne prenait que la version 11.
C'était pas compatible avec les fonctionnalités qu'on utilisait. J'ai eu le même problème.
Il y a un acteur suisse qui a Zurich qui s'appelle Stormkit. Il ne prenait pas tout en charge sur
Next JS 12. Tu vois, tu as vraiment une adaptation d'épée à forme qui est obligatoire pour prendre
en charge le framework. Et Stormkit, tu dis ?
Oui, Stormkit. C'est un acteur qui est Azurek, en Suisse, qui est pas mal.
Ce petit acteur européen qui propose un système de déploiement qui tourne sur AWS, évidemment.
C'est une surcouche de AWS, c'est ça ?
Oui, c'est une surcouche, comme la plupart des outils.
Je ne sais pas si ça s'appelle, mais juste un peu plus bas. Vas-y, descend sur le site.
Ah oui, c'est la Eagle.
Donc il y a Next et il y a d'autres boîtes qui testent ça.
Et pourtant, ils annoncent comme quoi ? Ils gèrent Next ?
Oui, mais pas toutes les fonctionnalités comme la réhydration.
Oui, c'est l'incrémentale, la régénération des pages, qui est proposée sur Next JS.
Et ça, ils ne le prenaient pas en compte. Il y a un mois ou deux mois, mais peut-être qu'après, ils ont travaillé.
Maintenant, c'est pris en compte. Mais voilà, ça demande vraiment un effort des plateformes
de prendre en charge. Parce qu'en fait, leurs plus-values par rapport à tout ce qu'on a discuté avant,
c'est que vraiment, en trois clics, tu peux te déployer une application.
C'est juste incroyable.
En fait, quand tu montres ce genre de service à un développeur qui n'a jamais utilisé ce système,
la première fois, c'est la réaction.
C'est incroyable.
En deux clics, j'ai linké mon GitHub.
Et c'est déjà déployé. Il y a une URL, il y a tout.
J'ai rien à faire, en fait.
C'est juste magique.
Et là, il va dire, oui, mais tu vas me mettre au chômage, tout.
Non, la plupart du temps, non, parce que ça améliore vraiment l'expérience développeur.
Et honnêtement, qui aime faire du serveur ?
Après, il y a des gens qui sont dédiés à ça.
Voilà, il y a des gens dédiés qui aiment ça, mais qui sont plutôt à l'aise sur les consoles,
tout ça. Mais sinon, la plupart des développeurs, ils aiment pas ça.
Et on en avait déjà parlé dans l'épisode sur les news,
mais il y a un service de flight control, justement,
qui vient se mettre en surcouche de AWS,
parce que c'est un viole visuel, la commande graphique
de Amazon,
ou alors, c'est de la configuration Yamel,
donc peut-être qu'on n'a pas envie de passer par là non plus.
Du coup, le juste intermédiaire, c'est justement
un truc qui vient se mettre entre les deux,
et ça s'appelle flight control.
Alors, c'est...
En fait, tu vas me dire qu'il n'y a pas quelle est la différence
avec Versailles ou Netflix, puisque c'est un peu la même chose.
C'est une interface qui est branchée à AWS.
En fait, la différence principale, c'est que eux,
tout est transparent. En fait, tu vas payer AWS,
ta facture classique, et eux, ils prennent un pourcentage dessus
en utilisant leur interface.
Donc, simplement, c'est juste une interface qui te permet de déployer facilement.
Et tu payes, ils prennent juste un pourcentage.
C'est un intermédiaire, en gros, une sur couche.
Donc, c'est ça la grosse différence.
Il y a un acteur français qui s'appelle Covri.
Par contre, il fait...
Je vais essayer Fly.
Du coup, je vais essayer un acte méditable.
Je déploie,
et ça va se runner,
ça va se run
sur AWS, Digital Ocean,
ou Skyway.
Et après, ça autoscale directement.
Oui, c'est pareil.
Et donc, pareil,
le pricing,
c'est...
Ça va être trop user.
En fait, c'est au déploiement.
Ok.
En fait, tu vas avoir soit tes limités
sur ton nombre de déploiements par mois,
et après,
tu vas avoir autant d'applications,
tu peux les payer...
En fait, c'est surtout au nombre de déploiements,
que tu vas payer au nombre de déploiements que tu fais.
Oui, c'est intéressant.
C'est pas mal, oui.
C'est simple.
Tu mets tes credits d'un show
sur AWS,
tu payes ta facture
sur AWS,
et eux, ils gèrent tout le reste.
Oui, c'est un petit peu différent
Covri par rapport à Fly Control,
ou vraiment Fly Control, ils prennent un pourcentage.
Covri, tu payes quand même le service,
et tu payes en plus à AWS,
mais c'est pas mal aussi.
C'est une surcouche qui te permet de...
Après, tu vois,
le compte-free, quand tu vois 100 déploiements
par mois,
enfin, sur certains sites,
s'il déploie 4 fois dans le mois,
c'est le bout du monde, sur un petit site.
Donc...
Mais la question, c'est est-ce qu'on déploie le vendredi ?
Si tu as fait tes tests,
et que tu es sûr que ça marche,
vraiment, tu déploies le vendredi.
Oui, oui, tu peux mettre comme ça,
tu parses ça, hein.
Yes !
Beaucoup d'infos,
beaucoup de services
à tester,
et...
hyper intéressant tout ça.
Hyper intéressant.
Donc on voit que, majorité de services
ce us, mais il y a quand même quelques acteurs français
qui offrent des bons services,
donc faut pas hésiter
à les tester, quoi.
Clever Cloud,
Scaleway,
Skylingo,
et qui offrent des bons services.
Et de toute façon,
on mettra
toutes les références de ces services-là,
on les mettra dans le lien
de l'épisode.
Ça marche.
Et bien, un grand merci à tous,
merci d'être restés jusqu'au bout,
pensez à mettre un petit pouce,
un petit like, partagez
l'épisode ou le podcast
avec vos collègues,
avec vos amis.
Et si ils sont devs, si ils sont pas devs,
ça risque d'être un peu compliqué pour eux.
Mais voilà,
ça nous aide beaucoup, c'est super cool.
Yes !
Un grand merci à tous !
Merci, ciao !
Durs l'émission.