- Titre original : Serverless Is the New Timeshare , Auteur : Shai Almog
Vous vous souvenez des mainframes ? Sans serveur, c'est comme : nous possédons cette machine, vous venez me la louer. L'innovation naît souvent sur les épaules de géants !
Les vacances en temps partagé sont un modèle de vacances originaire d'Europe, qui divise le droit d'utiliser une chambre d'hôtes ou un appartement touristique dans un hôtel ou un complexe en plusieurs semaines, avec une période de 10 à 40 ans, voire plus. système est vendu aux clients en une seule fois, et les membres bénéficient d'un moyen de loisirs de séjourner dans des hôtels ou des centres de villégiature pendant 7 jours par an. Et grâce au système de service d'échange, les membres échangent leurs propres droits d'utilisation de chambre avec les droits d'utilisation de chambre hors site d'autres membres, afin de réaliser l'objectif de voyager à divers endroits à faible coût.
Avec le recul, le serverless est le nouveau timeshare !
Nous sommes tous amnésiques. Lorsque je parle à de jeunes développeurs de technologies du passé, j'ai souvent des regards vides. Pour être honnête, c'est en partie parce que je suis un peu "nerveux" ou "bizarre", mais en partie parce que les jeunes technophiles ne comprennent pas la vieille technologie.
Par exemple : Certains jeunes techniciens n'ont aucune idée de ce qu'est l'engagement en 2 phases. Est-ce que la gestion des transactions n'est plus nécessaire ?
Les banques n'ont-elles plus besoin de cohérence ? Cette technique fonctionne en transférant le contexte de transaction entre différents serveurs si vous n'êtes pas sur la "même page". Ainsi, un commit sur un serveur est un processus en plusieurs étapes qui est presque garanti de réussir sur tous les serveurs ou de revenir en arrière en un seul. C'est assez étonnant et fonctionne plutôt bien (avec quelques mises en garde évidemment). Étonnamment, ceci est réalisé par des appels de méthode. Vous n'avez rien à faire, cela fonctionnera très bien même en appelant la méthode distante sur un serveur complètement différent.
Il y a quelques années, je parlais à une startup du secteur bancaire appelée Node-based. Les banques sont très ouvertes à travailler avec Node, ont-ils déclaré. Je sais qu'ils réécrivent leurs trucs dans un environnement plus "mature". Lorsque j'utilise des outils "plus récents" comme Node, je suis toujours surpris par le manque de fonctionnalités de base. Bien sûr, c'est plus simple et plus petit si vous n'y mettez pas tout ce dont nous avons besoin. Il est facile de créer quelque chose de simple lorsque vous abandonnez les fonctionnalités de base.
Les drames NoSQL des années 2010
En 1999, je créais mon propre cabinet de conseil lorsqu'un ami m'a demandé de rencontrer son patron. Je suis allé dans ce bureau et le "patron" a dit qu'il avait l'idée la plus incroyable que personne d'autre n'avait eue. Ils ont le financement et seront lancés dans 6 mois et déployés auprès de 1 million d'utilisateurs dès le premier jour !
moi : d'accord. quelle idée?
Lui : Je vous le ferai savoir après votre inscription pour travailler pour nous.
Moi : Je signerai un NDA (NON-DIVULAGE AGREEMENT, c'est-à-dire un accord de non-divulgation).
il ne fait pas. C'est une excellente idée. Ces NDA ne valent rien. tu t'inscris et...
D'une manière ou d'une autre, j'ai pu résister à la tentation de travailler pour cette entreprise. Après environ un an, ils ne se sont évidemment pas lancés, mais mon cabinet de conseil se porte très bien. Mon ami m'a encore appelé. Cette fois, ils avaient besoin d'aide avec le produit, alors je suis allé là-bas en tant que consultant pour les aider.
L'idée est d'avoir une application de chat intégrée au site Web afin que les visiteurs du site puissent discuter entre eux. Un concurrent s'est lancé et je consulte plusieurs autres sociétés ayant la même idée. Au lieu de cela, ils se concentrent sur le chat lié au commerce électronique. Mais je m'égare...
Leur système fonctionnait très mal. La vitesse d'un utilisateur est aussi lente qu'une fourmi collée au miel. Apparemment, le PDG était catégorique sur le fait qu'ils devaient pouvoir prendre en charge 1 million d'utilisateurs dès le premier jour (comme il me l'a dit). Ils ont communiqué cela à Oracle Corporation, qui a déclaré avoir besoin d'un cluster de trois serveurs pour prendre en charge cette capacité. Ensuite, ils ont parlé à un fournisseur de bases de données orientées objet qui a promis de pouvoir gérer un million d'utilisateurs sur une seule machine. Ils ont donc opté pour des bases de données orientées objet. Quand j'ai été choqué par cela, ils ont affirmé que leurs données étaient très "orientées objet" en ce sens que chaque utilisateur pouvait avoir plusieurs éléments... duh.
Ils ne comprennent pas les limites des transactions, le code du magasin est mélangé à tout le code et ils sont lents. Ce n'est pas fiable et incompréhensible. Vous ne vous souvenez peut-être pas de l'époque des bases de données orientées objet, mais c'était un précurseur de la mode NoSQL qui a balayé notre industrie dans les années 2010. Pendant mon temps en tant que consultant, j'ai revu des rediffusions de cette histoire. Cette fois, la plupart des entreprises se sont lancées avec succès.
Mais ensuite, ils ont découvert que le fait d'avoir des données non structurées n'est pas une panacée. Le gain de performances qu'ils gagnent est négligeable par rapport à la simple utilisation d'une bonne mise en cache et d'un SQL bien réglé. Les histoires de déploiement sont complexes et les outils d'assistance peuvent ne jamais atteindre le niveau que nous avons dans le monde SQL.
Pour être clair : NoSQL a son créneau, mais les usages courants de ces bases de données ne sont pas très bons et relèvent du RDD (Recovery Driven Development). Voici le modèle que ceux d'entre nous qui ont fait le tour du pâté de maisons plusieurs fois ont vu maintes et maintes fois :
- • L'ancienne technologie est lourde et complexe
- • Les gens ont inventé quelque chose de propre et simple
- • Oubliez l'ancienne technologie
- • Les nouveautés sont simplistes et ne font pas beaucoup de choses de base
- • Remodeler ces complexités
- • Les nouveautés deviennent anciennes et une complexité maladroite qui doit être réinventée... rincer/répéter
Serverless est le nouveau mainframe
J'ai fait beaucoup de travail sans serveur au cours du mois dernier, et j'ai l'impression que c'est un grand pas en arrière. Il s'agit d'une répétition du même problème que nous avons avec PaaS. C'est en fait un ordinateur central. Dans le passé, nous avions l'habitude de payer pour exécuter nos travaux sur des mainframes à usage partagé. C'est un peu comme un environnement virtualisé , mais l'idée est similaire : nous ne sommes pas propriétaires de l'environnement. La même chose peut être dite pour le cloud SaaS, mais sans serveur pousse le concept très loin.
Même l'expérience de débogage est nulle. Nous n'avons aucun contrôle fondamental sur notre code ou sur la logique d'application de base. J'essaie de comprendre pourquoi les gens l'utilisent pour autre chose que des tâches de base.
Je peux penser à un bon cas d'utilisation : les webhooks. Obtenir le code de plomberie pour un webhook est toujours pénible. Ils se déclenchent rarement et y faire face est une corvée. Cela peut être aussi simple que d'ajouter du contenu à une base de données et de faire le travail à l'aide de fonctions sans serveur. Comme il est difficile de déboguer les rappels de toute façon, une mauvaise expérience de débogage sans serveur n'est pas un énorme obstacle. Mais pour tous les autres cas d'utilisation, je suis absolument perplexe.
Les gens passent beaucoup de temps à vérifier et à mesurer le débit, mais en utilisant seulement un serveur légèrement plus grand, et seuls les appels locaux produisent plus de débit que vous n'en avez probablement besoin. Sans tous les regroupements de fournisseurs avec lesquels nous sommes coincés. Vous économiserez beaucoup d'argent avec un hébergement comme Linode, Digital Ocean, etc. En termes de délai de mise sur le marché, le simple fait d'utiliser un cache et des outils locaux rapides sera beaucoup plus facile que tout ce que vous pouvez créer dans le cloud.
Les conteneurs sont une grande avancée, ils rendent cela beaucoup plus facile, mais nous sommes dépassés par la complexité de l'utilisation des conteneurs, comme K8S. Ne vous méprenez pas. K8S est génial. Mais 98% d'entre nous n'en ont pas vraiment besoin, et nous ne devrions pas non plus l'utiliser. Si vous êtes une petite startup, Kubernetes est une perte de temps et d'énergie.
Retour à Java et Rust
Java est un exemple qui fait un excellent travail "d'oubli". Nous avons Smalltalk et c'est génial. Lorsque Java est sorti pour la première fois, c'était une solution inférieure avec un style de syntaxe C étrange. Java a jeté de nombreuses idées géniales dans Smalltalk et C++. Il emploie des idées controversées (exceptions vérifiées, primitives, etc.). Pourtant, cela a fonctionné. Il attire l'attention, il peut capitaliser là-dessus.
Il a commencé comme un langage léger qui éliminait toutes les ordures et la sur-ingénierie que d'autres plates-formes avaient ajoutées. Regardez maintenant, personne ne l'a plus décrit comme "léger". Les développeurs sont occupés à créer des langages plus légers et plus simples pour se plaindre des bugs de Java. Le succès les ramènera là où nous avons commencé. Un langage léger qui a trop grandi. Java est là où il devrait être en ce moment. C'est l'un des rares exemples d'une bonne réécriture.
La rouille semble également être l'une des rares exceptions. Il réinvente le C d'une toute nouvelle manière. Il est difficile de dire s'il survivra à long terme. Mais ne vous y trompez pas, cela demande beaucoup de complexité en cours de route.
remodelage conscient
Qu'est-ce qui fait la réussite de la réinvention d'un langage ou d'un outil existant pour le marché de masse, et qu'est-ce qui fait que ces outils sont abandonnés ?
SQL est de retour d'entre les morts et est à nouveau un favori des nouvelles startups. On ne peut pas en dire autant du C++. Comment sont-ils différents?
Malgré l'absence des fonctionnalités de base que nous avons dans le monde JVM, Node et Python sont toujours populaires. Alors que se passe-t-il, et maintiendront-ils cette popularité ? Vont-ils rajouter ces choses ?
Jusqu'à l'adolescence, notre cerveau ajoute constamment des synapses. Dans notre adolescence, nous les avons coupés. Une théorie est que cela est à l'origine de tous les changements que nous vivons à l'adolescence. Nous devons déconnecter ce qui ne fonctionne plus pour nous. Sinon, nous n'apprenons que ce que nos parents savent. Nous ne pouvons pas nous améliorer en faisant nos propres erreurs. Essayez à nouveau ce que cette génération a échoué.
En conséquence, nous avons répété nos erreurs et en avons commis de nouvelles horribles. Nous avons également fait des sauts et des découvertes incroyables. C'est là que l'innovation prend son envol, tout comme l'ingénierie.
Comment faire la différence : anxiété adolescente et nouvelles directions lumineuses ?
Honnêtement, nous ne pouvons pas. En tant que personne âgée, quand j'ai vu ce genre de choses pour la première fois, beaucoup de choses m'ont semblé idiotes. Nous avons essayé ces choses et avons échoué. Pourquoi répéter cette mauvaise direction ? C'est là que réside l'innovation. Cependant, si nous examinons de près les tentatives réussies, nous pouvons voir ce qui a fonctionné pour elles.
Java n'a pas été conçu pour mettre fin à C++. Bien sûr, cela pourrait être une illusion. Mais Gosling l'a conçu pour la simplicité et la légèreté. Pour aborder un créneau très étroit, concentrez-vous sur la sécurité, l'évolutivité et la mise en réseau.
Rust n'est pas conçu pour tuer C. Il est conçu pour rendre des projets comme Firefox plus stables et performants.
Je pense que les inventions secondaires, comme toute startup, fonctionnent bien lorsque nous nous limitons initialement à un cas d'utilisation très petit et étroit. En faisant cela et en maintenant cette concentration initiale, nous pouvons construire quelque chose de bien et ensuite faire de grands pas en avant.