1/02/2019

103 extraits pour comprendre la disruption 💥

Ah ! J'avais hâte d'écrire ce billet 💥! La lecture du livre Disruption de Stéphane Mallard fut pour le moins... rafraichissante 😭. Sans plus d'introduction, je te laisse apprécier quelques extraits choisis...

Introduction

A chaque annonce d'une ambition de disruption dans un domaine, on interroge des spécialistes qui se précipitent à la minimiser, voire à brandir son impossibilité, alors que les experts ont toujours eu tort sur la disruption parce qu'ils l'analysent avec des modèles qu'elle a déjà rendus obsolètes
Face à la disruption, il n'y a désormais plus qu'une seule option : se disrupter soi-même pour éviter de se faire disrupter. C'est l'ambition de ce livre : vous donner les clés pour appréhender ce monde en train de naître, ne pas le craindre et éviter que d'autres ne le bâtissent à notre place.

Les chatbots: discuter avec les machines

Google prépare déjà l'avenir de son moteur de recherche avec un objectif radical : le faire disparaître.

Enjeux pour les entreprises

D'abord parce que dès qu'une solution d'intelligence artificielle sera intégrée avec succès pour optimiser un processus ou améliorer la connaissance client, chaque concurrent répliquera immédiatement. Les entreprises d'un même secteur se retrouveront vite au même niveau de maturité technologique avec l'intelligence artificielle, et la concurrence classique continuera à se faire par les prix. Autrement dit, pas de création de valeur, simplement de la récupération de valeur existante, sur des marchés existants.
De la même manière kodak n'a pas compris que l'arrivée des appareils photo numériques rendait son activité d'impression de photos obsolète, beaucoup d'entreprises aujourd'hui ne comprennent pas que l'activité qui fonde leur raison d'être pourrait être balayée par l'intelligence artificielle. L'enjeu pour les entreprises est stratégique : il ne s'agit pas d'injecter de l'intelligence artificielle dans leur activité actuelle pour la poursuivre en mieux, mais de se poser la question, une fois qu'elles ont compris les potentiels de l'intelligence artificielle, de l'existence même de leur activité.

Disruption de l'entreprise par les assistants intelligents

Le fonds d'investissement BridgeWater Associates, lui, supprime tous ses managers, qu'il remplace par de l'intelligence artificielle. Et ce n'est que le début de l'impact de l'arrivée de l'intelligence artificielle dans l'entreprise.
Bientôt, plus aucune décision stratégique ne sera prise sans être validée par l'intelligence artificielle à tous les niveaux de l'entreprise. Jack Ma, le fondateur d'Alibaba, l'Amazon chinois, va encore plus loin. Selon lui, d'ici moins de trente ans, ce sont les intelligences artificielles elles-mêmes qui dirigeront les entreprises.

Etre choisi ou mourir

Comme Google, dont l'algorithme de recherche sélectionne aujourd'hui les sites les plus pertinents, les ordonne et les affiche sur sa première page, notre assistant intelligent sera un filtre sur le monde pour nous protéger et optimiser nos décisions. Pour les entreprises, cela implique que de la même manière qu'aujourd'hui elles doivent convaincre l'algorithme de référencement de Google pour avoir une chance d'exister sur sa première page lors d'une recherche, elles devront demain convaincre l'assistant intelligent de leur client de les sélectionner selon une liste de critère qui dépendra de chaque client. Pour une parvenir une seule solution : être parfaitement honnêtes et transparentes avec l'assistant du client.
Cette exigence d'honnêteté pourra même conduire à des situations contre-intuitives aujourd'hui : une entreprise pourrait finir par recommander le produit de son concurrent. Elle perdrait une vente mais gagnerait la confiance de l'assistant intelligent de son client qui n'hésitera pas à la re-solliciter à l'avenir.

Demain, être salarié sera synonyme d'incompétence

Avec la révolution digitale, la circulation rapide de l'information et l'avènement des plateformes d'indépendants, les coûts de transaction avec des travailleurs indépendants chutent considérablement et tendront bientôt vers zéro : il devient facile et peu cher de solliciter et contractualiser avec des travailleurs indépendants. Dès lors, tous les problèmes et toutes les inefficacités du salariat qui auparavant étaient négligeables par rapport au coût d'emploi d'indépendants deviennent déterminants. En les analysant et en les comparent il est évident que le salariat est condamné à disparaître, et qu'entre-temps, seuls les travailleurs les moins compétents chercheront à être salariés.
Le salariat est un marché imparfait dépassé par notre époque. Le digital exacerbe la concurrence pour un même travail entre salariés et indépendants. Les indépendants gagneront parce qu'ils produiront un signal de meilleure clarté sur leur niveau réel de valeur ajoutée et obtiendront une rémunération en adéquation. Le salariat disparaîtra.

Les digitals nomads ou la génération CEO qui refuse le salariat

Pourquoi accepter d'être une marge financière pour son employeur là où l'on pourrait être mieux rémunéré en étant indépendant ? Les digital nomads refusent ce salariat qui signifie aussi pour eux passer du temps à faire de la politique interne : choisir son camp, devoir influencer et protéger ses soutiens dans l'entreprise, se protéger soi-même en permanence, préparer le terrain pour prendre le prochain poste, devoir participer aux ragots à la machine à café...

Du client oublié au business disrupté: le dilemme de l'innovateur

La plupart du temps, les dirigeants comprennent la disruption des autres industries : elle est toujours évidente une fois qu'elle a eu lieu et s'explique facilement. mais ils estiment leur propre disruption peu probable. Pire, ils suivent les tendances sociétales et technologiques mentionnées dans les rapports des cabinets de conseil et s'imaginent comme des acteurs de premier plan des révolutions à venir alors que c'est l'attitude la plus dangereuse à adopter face à la disruption.

L'expérience exceptionnelle ou la mort

Si Amazon construisait des aéroports, comment penserait-il l'expérience ? Une chose est sûre : en bannissant le moindre effort et le moindre temps perdu pour les usagers. [...] Offrir une expérience exceptionnelle à large échelle est possible : les géants de la Tech le prouvent tous les jours (y compris dans les domaines physiques comme la logistique). Nous devons désormais exiger ce niveau d'expérience. Si les hôpitaux, les écoles, les aéroports ne s'alignent pas, alors Amazon (ou un autre) créera ses hôpitaux, ses écoles et ses aéroports.

Tous paresseux. Mais tous autonomes

La disruption ne tolère pas l'effort. La simplicité est devenue la norme. Toute expérience doit désormais être suffisamment simple pour relever de l'intuition. Si un client ou un utilisateur a besoin d'être guidé, formé ou d'avoir recours à un mode d'emploi pour utiliser un produit, un service, une application, c'est que la simplicité n'est pas respectée.
Beaucoup d'entreprises, dans leur stratégie de transformation digitale, insistent sur le besoin de leurs collaborateurs de formation au digital, à de nouveaux usages et de nouveaux outils. Les gouvernements évoquent eux aussi le besoin de formation au digital pour réduire la fracture numérique, au nom de l'inclusion. C'est une grave erreur qui prend le problème à l'envers. Ce n'est pas à l'utilisateur d'être formé, c'est aux produits, aux applications et aux procédures d'être conçus pour être utilisés de manière intuitive, sans aucune formation. Il n'y a pas besoin de mode d'emploi pour utiliser les produits Apple, il suffit de voir avec quelle facilité un jeune enfant se sert d'un iPad. De même, personne n'a besoin qu'on lui explique le fonctionnement d'Amazon, Uber ou Netflix : tout est pensé pour guider l'utilisateur sans effort. Pourquoi en serait-il autrement de toutes nos interactions avec une entreprise et avec l'Etat ?

Le darwinisme de la foule connectée

Les journalistes sont dorénavant en concurrence avec des amateurs via les blogs ou les réseaux sociaux et ce sont les plus pertinents qui sont les plus suivis et les plus écoutés ; ils deviennent des références, deviennent influents. Les professeurs sont en concurrence sur Youtube et sur les MOOC avec des vulgarisateurs amateurs. Là encore, ce n'est plus le titre de professeur qui légitime la compétence à enseigner et transmettre mais le nombre de vues, de partages et la réputation qu'ils se construisent à véhiculer de l'information juste et de qualité.

La mort de la communication corporate

Un leader charismatique n'a pas besoin d'évoquer son charisme, de la même manière qu'une personne honnête n'a pas besoin d'insister sur son honnêteté, sinon le signal envoyé est l'exact opposé et génère de la méfiance et du rejet. Lorsqu'une entreprise a besoin de communiquer sur des valeurs, sur la qualité de ses produits ou l'excellence de son service, la confiance de ses clients ou des prix/classements qu'elle a obtenus, c'est désormais un signe de faiblesse qui vise à masquer ses inaptitudes.

Le piratage de votre attention : valeur ultime

A force d'utiliser ces technologies de manière intensive, notre cerveau est transformé dans des mesures que nous ne comprenons pas encore très bien [...]. Dans une interview de 2009, Eric Schmidt, le CEO de Google, évoquait déjà ses inquiétudes : "j'ai peur que le niveau d'interruptions, la rapidité incroyable de l'information et surtout de l'information stressante n'affecte notre cognition, que cela affecte notre capacité à avoir des réflexions profondes. [...]"

Accélération de la mondialisation

[...] pour atteindre 50 millions d'utilisateurs, il a fallu 75 ans au téléphone, 38 ans à la radio, 13 ans à la télévision, 4 ans à Internet, 3 ans et demi à Facebook, 6 mois à Instagram et 19 jours à une application comme Pokemon Go.

Accélération invisible

Notre cerveau est habitué à la lenteur, il a conception linéaire du monde et est incapable d'appréhender l'exponentiel. nous avons tendance à imaginer que le futur se déroulera au même rythme que le passé [...]

L'instantanéité à tout prix

L'exigence de rapidité pousse à sortir les produits non finis, voire dangereux. La première version de la Tesla Roadster était un désastre et était même dangereuse selon son créateur Elon Musk. Quant au smartphone Samsung Note 7, il a provoqué un scandale mondial à cause de ses batteries qui explosaient et prenaient feu. Les entreprises préfèrent confronter rapidement leurs produits au marché puis itérer sur les prochaines versions au détriment de la qualité et au risque de mettre en danger leurs clients. Reid Hoffman, le co-fondateur de LinkedIn le répète souvent : "si vous n'avez pas honte de votre produit, c'est que vous l'avez sorti trop tard". Il n'y a plus de temps pour la réflexion stratégique; les décisions sont immédiates et la trajectoire s'ajuste en route. Les stratégies business à moyen terme sont caduques parce que désormais seule l'adaptation à cette nouvelle exigence de rapidité est récompensée au péril de l'entreprise en cas de scandale.

La chute des premiers de la classe

[...] même si tous ces employés ont des profils différents, ils ont en général un point commun mortal face à la disruption : ils ont peur de prendre des risques, alors que la disruption exige la prise de risque. Et les entreprises sont responsables de cette ressemblance des profils face au risque à cause de leur manière de les recruter.
L'école ne forme pas à la disruption; elle sélectionne et récompense ceux qui savent réussir un concours et épouser ses codes. Certaines écoles ont perçu le besoin d'entreprendre face à la disruption et offrent des formations pour devenir entrepreneur : elles n'ont pas compris que les entrepreneurs qui disruptent le monde étaient déjà occupés à le faire.
La psychologie du disrupteur consiste à transgresser en pensée et en action. Suivre les règles reste évidemment indispensable dans de nombreux métiers. Suivre les règles reste évidemment indispensable dans de nombreux métiers. [...] Mais pour réinventer des secteurs en place il est indispensable de le faire avant qu'un nouvel acteur — qui lui n'a rien à perdre — ne le fasse à votre place.

Le handicap de l'expérience et de l'expertise

Les disrupteurs n'acceptent plus l'opinion des spécialistes parce qu'ils sont les pires à évaluer leur propre disruption. [...] Beaucoup d'entreprises font l'erreur de faire appel à ces cabinets de conseil pour se transformer. leurs consultants se présentent comme des spécialistes du digital, parfois même de la disruption et les entreprises pensent réussir leur transformation en écoutant leurs conseils : c'est une erreur qui peut leur coûter très cher. Imaginez si avant l'arrivée d'Uber, les taxis avaient fait appel à un cabinet de conseil pour faire leur transformation digitale. Pensez-vous que les consultants leur auraient conseillé de créer une application qui les mette en relation directe avec leurs clients (autrement dit d'inventer Uber) ? C'est impossible pour trois raisons. D'abord parce qu'imaginer où sera la valeur d'une activité face à la disruption avant tout le monde est la compétence de l'entrepreneur, pas du consultant. Ensuite parce que le consultant a une aversion pour le risque : son business model est de prendre l'argent de celui qui prend des risques (l'entreprise qu'il conseille) — sinon il serait entrepreneur. Et enfin parce que même si le consultant est spécialiste du digital, il ne fait pas partie des plus compétents du marché — sinon il serait immédiatement recruté par l'un des pure players du digital qui s'arrachent les talents aux meilleurs salaires. Il est irrationnel pour une entreprise de faire appel à un cabinet de conseil face à la disruption, les entreprises doivent absolument rompre avec cette habitude. Les consultants sont les moins à même d'aider les entreprises dans leur transformation.
La disruption arrive toujours dans un secteur par des non-professionnels, y compris par de très jeunes, sans expérience professionnelle. L'inexpérience n'est plus synonyme de naïveté face à la disruption : c'est un aout qui permet de voir le monde autrement. Pourtant, les entreprises traditionnelles méprisent encore l'inexpérience.
Un junior ou un stagiaire peut avoir plus d'idées pour disrupter l'entreprise dans laquelle il travaille qu'un manager expérimenté. Son regard neuf n'a pas encore été censuré par la structure, la politique interne et les habitudes.
Pour ne pas subir la disruption, la logique voudrait que les entreprises renversent leur attitude face aux jeunes générations et les associent à leurs décisions les plus stratégiques au lieu de les considérer comme des originalités qui nourrissent leurs décisionnaires.

Sociologie des organisations disruptives

Les grandes entreprises traditionnelles sont condamnées au statu quo. Même si elles annoncent de grandes transformations et des places stratégiques à cinq ans, leurs employés font tout pour empêcher le changement, parce que ces entreprises sont construites sur des idées de rentabilité plus que de mission. Les employés sont recrutés pour être performants et atteindre leurs objectifs plutôt que de le faire pour changer le monde avec une mission affichée.
Ce qui aveugle les dirigeants, c'est de partir du principe que ce qui a de la valeur pour un client aujourd'hui en aura toujours.

Sabordez-vous et pivotez comme un entrepreneur. Vite.

Ce qu'elles [NDLR: les entreprises] doivent faire, c'est être prêtes à saborder leur business et à abandonner leur business model. Il faut s'imaginer déjà mort pour penser autrement son activité et se demander où sera la valeur dans le futur. Les entreprises traditionnelles n'y arrivent pas, tandis que les disrupteurs raffolent de l'exercice.
Mais pour se saborder, il faut une vision. Les gestionnaires doivent disparaître pour laisser la place à des entrepreneurs, dont c'est précisément la compétence d'être capable de voir avant tout le monde la valeur dans le futur. Si vos dirigeants n'ont pas de vision, ils ne sont plus à leur place face à la disruption. Imaginez si un disrupteur comme Elon Musk était placé à la tête d'une industrie vieillissante qui refuse le changement comme une banque ou une société d'aéroports : il y aurait des annonces de nouveautés tous les jours et le changement irait encore plus vite que tout ce que nous imaginerions. On ne dirige plus une entreprise face à la disruption avec des plans stratégiques à cinq ans et des objectifs de conquête de marché : le marché ne sera peut-être plus là. Il faut choisir la rupture ou la disparition.
Les disrupteurs commencent petit, en s'attaquant à des marchés très spécifiques (Amazon a commencé par vendre des livres) ou localisés (Uber a d'abord été lancé à San Francisco). Ils écoutent le feedback de leur marché en permanence pour adapter leur produit ou service et itérer jusqu'à trouver leur product market fit, c'est-à-dire ce que demande exactement leur cible de clients ou d'utilisateurs.

Ne cédez pas au bullshit ambiant de l'innovation pour tous

Non, vous ne deviendrez pas disruptif en créant une direction de l'innovation ou un "lab" dans votre entreprise, avec un directeur de l'innovation en costume et des équipes chargées de thèmes buzz-words comme l'équipe "big data" ou l'équipe "expérience client".

Customer Obsession: quand un client mécontent vaut de l'or

Dès le début d'Amazon, son CEO Jeff Bezos avait l'habitude d'intégrer et de personnifier une chaise vide en réunion qui symbolisait le client et qu'il mentionnait comme "la personne la plus importante de la salle" pour rappeler aux personnes présentes en réunion que tout ce qui était décidé l'était pour elle, pas pour eux.

La fin des hiérarchies

Dans un email d'août 2017, Elon Musk exhortait les employés de Tesla à mettre fin à cette pratique ancestrale dans l'entreprise qui oblige les employés à se référer et à communiquer toute information pertinente à leur manager direct. "Passer l'information de manager à manager puis d'un département à l'autre est une manière débile de procéder", "tout le monde chez Tesla doit pouvoir communiquer avec n'importe qui selon ce qu'il juge être le plus rapide pour résoudre un problème dans l'intérêt de l'entreprise" dit-il. Le message est violent et direct, mais il illustre bien la fin d'un mythe dans l'entreprise face à la disruption : celui des hiérarchies et des silos.

Pour toi le digital est avant tout une affaire de doigt ? Tu manges des nuages au réveil ? Ca tombe bien, j'écris en ce moment un livre à destination des techs "#Nobullshit Tech-Lead", n'hésite pas à t'inscrire à la newsletter ci-dessous pour en savoir plus !

10/31/2018

How to backup Cloudflare DNS settings

Just made a weekly backup script of Image-Charts @Cloudflare DNS settings in BIND format.

It's based on flares and Gitlab CI pipeline schedules & artifacts

Find the 3-steps tutorial and .gitlab-ci.yml file here

10/15/2018

[Fr] 4 mois plus tard, retour sur le talk "Choisir entre une API RPC, SOAP, REST, #GraphQL et si le problème était ailleurs ?"

Depuis juin dernier je souhaitais vous proposer un feedback sur le talk Choisir entre une API RPC, SOAP, REST, #GraphQL et si le problème était ailleurs ? qui avait eu lieu au Web2Day à Nantes.

Comme le veut la coutume, j'en ai profité pour partager quelques stickers d'Image-Charts et de Redsmin!

Wow !

Bien que le sujet soit touchy — s'attaquer à la doxa concernant les SGBDR et essayer de montrer qu'il y a d'autres voies n'était pas gagné d'avance —, les réactions ont été très positives !

Si vous n'avez pas pu assister au Web2Day, bonne nouvelle, les replays sont disponibles sur YouTube et voici l'intervention en question :

Questions / Réponses

Ce talk a aussi suscité des questions après la conférence et comme elles me sont souvent posées lorsque j'aborde ces sujets, je profite de ce billet pour y répondre afin d'y référer les prochains interlocuteurs 😁.

Comment sécuriser les appels ?

En fonction de la présence ou non de la JWT lors de l'appel ainsi que des privilèges associés aux rôles sur les vues et fonctions stockées (cf. le talk) les appels nécessiteront ou pas une authentification.

Je suis plus productif avec un ORM qu'en écrivant du SQL directement

Sans entrer dans le sujet ORM (qui d'ailleurs serait un débat passionnant), SQL est partout même là où on ne l'attend pas que cela soit en Big Data (Kafka KSQL, Spark, Flink) ou en NoSQL (Elasticsearch SQL, Cassandra CQL). Ceci pour expliciter que l'argument selon lequel un développeur n'aurait pas besoin de connaitre SQL est aussi caduque que la pensée qu'un développeur ne doit pas savoir écrire des tests ou connaitre OWASP top 10.

Les SGBDR et plus précisément PostgreSQL ont des fonctionnalités et permettent d'être déclaratif sur certaines problématiques comme la gestion des droits plutôt que de devoir re-développer à chaque projet un système from scratch. L'ORM ne résout pas le sujet des autorisations et même (c'est là où la discussion est intéressante), même si nous trouvions un ORM gérant les autorisations, le problème fondamental est qu'elles seraient gérées au niveau de la couche applicative, laissant, en cas de faille (e.g. escalade de privilège), un accès complet à la base. C'est l'intérêt de travailler sur les couches les plus basses pour avoir des leviers (ici la sécurité) sur les couches supérieures.

Quid de la gestion des droits multi-tenant et de la séparation read/write ?

Gérer le multi-tenant avec une approche déclarative — en comparaison à une approche impérative — permet de respecter single-source-of-truth (il est structurellement bien plus difficile d'avoir la garantie qu'une règle d'autorisation sera appliquée — de manière future-proof — sur l'intégralité d'une code base lorsque l'on passe par du code). Dans le cas de RLS (Row Level Security), limiter un utilisateur pour qu'il ne voit que ses propres éléments dans la table X, peu importe comment elle sera accédée dans le futur (avec jointure ou pas) revient uniquement à déclarer using (user_id = request.user_id()) ou encore, pour limiter l'accès au niveau d'une organisation using (organization_id = request.organization_id()).

À noter qu'il n'est pas obligé de mettre les identifiants d'utilisateur, d'organisation ou de groupe en colonne de chaque table car ces informations sont très souvent déjà présentes au niveau de la JWT, la mise en place d'une function stable pour accéder à ces attributs à join est aussi possible et tout aussi efficace.

Pour la gestion des accès en écriture (à savoir create, update, delete), toujours en RLS, with check prend la relève et offre une approche unifiée permettant ainsi de distinguer — si souhaité — les accès entre les opérations de lecture (avec using) et d'écriture (avec with check).

Comment gérer les montées en version ?

De la même manière qu'une API doit la plupart du temps supporter N et N-1. Dans le cas d'une breaking, la montée de version nécessite d’avoir une compatibilité descendante. Cela passe (cf. le début du talk) par la mise en place d'un second schéma (e.g. v2), avec des vues et fonctions stockées qui pointent vers les schémas privés et qui retournent les données sous le nouveau format.

Il faut noter que cette notion de (1..N) schémas publiques et (1..N) schémas privés permet une flexibilité dans les développements et les itérations tout en respectant le principe de Single Source of Truth.

J'ai peur que le "code" finisse par n'être qu'une liste de scripts de migration ?

Pour compléter la réponse précédente, effectivement, il a été un temps où tout n'était que migration. Et c'est problématique car une suite de fichiers SQL représentant les migrations sont bien plus difficile à suivre qu'un ensemble de fichier SQL représentant l'intégralité de l'état final des schémas de BDD. Fort heureusement des outils apparaissent et permettent de se concentrer uniquement sur l'état final et de laisser l'outil générer les migrations entre l'état précédent et le nouvel état (cf. question ci-dessous sur "Comment bien démarrer"). Le(s) développeur(s) se concentrent donc uniquement sur sa version cible et laisse l'outil gérer les diffs. C'est une approche saine que l'on retrouve d'ailleurs dans d'autres domaines comme celui de la gestion de configuration d'infrastructure (e.g. Terraform).

Comment scale ?

Il y a deux réponses à cette question. La première concerne le scaling de l'API (PostgREST ou Subzero, ...) et ici il s'agit de scaling horizontal classique.

La seconde question qui vient juste après concerne le scaling de la base de données. Mais avant de parler de cela, il nous faut ici rappeler un point fondamental qui est souvent oublié. Sur le modèle présenté ici (API passe-plat vers la BDD), la base de données fait autant de travail que dans une approche 3 tiers, c'est même souvent (et c'est structurel) plus performant. Pourquoi ? Parce qu'au lieu de N requêtes à la BDD (authentification, autorisations, lectures ou écritures multiples) depuis une requête HTTP vers l'API, dans le modèle présent tout est résolu au sein d'une même requête, donc pas d'overhead sur l'aller/retour avec la BDD.

Ensuite, nous sommes en 2018, PostgreSQL est maintenant capable de gérer des quantités astronomiques de données (10 To chez Leboncoin par exemple). Quand je vois la taille des datasets des entreprises, dans l'immense majorité, cela ne dépasse pas la dizaine voir la centaine de Go, ce qui est un non sujet avec PostgreSQL. Encore une fois, comme je le dis dans le talk, ce style d'architecture permet de traiter environ 80% des usages en entreprise. Pour ces 80% il n'est pas nécessaire de monter un cassandra/mongodb en cluster lorsque le besoin est finalement de stocker de la donnée relationnelle (rappel : notre univers est relationnel) représentant moins de 100 Go.

Et si problème de scaling il y a, alors c'est une excellente nouvelle ! Le business aura crû progressivement (ou rapidement), l'approche DB-centric aura permis d'avoir un time-to-market très aggressif tout en gardant un investissement en développement réduit (grâce à ladite architecture). Il sera temps d'investir cette fois dans de l'optimisation au cas par cas tout en ayant une idée des volumes en jeu et des informations de monitoring sur les goulôts d'étranglement. Cela permettra de choisir une alternative de manière éclairée. Elle est pas belle la vie ? 😉

Comment bien démarrer ?

Le starter-kit de subzero (l'équivalent de PostgREST mais qui offre aussi GraphQL par dessus) est un excellent point de départ !

Aller plus loin

Un nouveau produit (open-source !) a fait son apparition sur le marché : Hasura. Sa courbe d'apprentissage est bien plus aisée que PostgREST (sur l'aspect initialisation du projet) car il expose une interface graphique pour créer ses différentes tables, déclarer les dépendances et propose un premier niveau de gestion de permission. C'est moins violent que de partir directement sur des migrations SQL pour les nouveaux arrivants. Hasura expose le tout sous forme d'API GraphQL (avec support des subscriptions temps-réel sans code supplémentaire !) et un support des webhooks for-free, faites vous plaisir!

Pour mysql il y a xmysql, même logique que PostgREST mais qui ne respecte pas SoC (Separation of Concerns), il fait papa/maman (upload de fichiers, génération de graphique, ...), bien pour prototyper mais je ne le recommanderais pas pour de la production.

Une dernière chose 😅📚!

J'ai commencé à écrire un livre sur "tout ce que j'aurais aimé connaitre avant d'être CTO" (nom temporaire) "D'un petit SaaS à forte croissance à une très grande entreprise".

C'est une collection de tous les principes et patterns que j'ai pu découvrir depuis 2012, allant de la spécification de l'organisation, de la mise à l'échelle des processus internes, du staffing et sourcing, du management, de la gestion de la production, des choix, avec bien sûr une large partie concernant le pendant technique et l'affinage d'une vision. Ces dernières années beaucoup de collègues m'ont demandé de réunir ces principes au sein d'un même endroit... nous y voilà ! J'espère terminer ce livre avant mon 30ème anniversaire (juste pour le challenge), il reste encore 9 mois et les principes fondamentaux que je répète chaque jour au travail sont là.

Le formulaire ci-dessous te permettra d'être notifié de sa publication 🐣!

Merci à David Sferruzza et Audrey Cambert pour leur relecture !

« »
 
 
Made with on a hot august night from an airplane the 19th of March 2017.