Simon Wardley visite des super-héros sans serveur
Bienvenue dans Serverless Superheroes!
Ici, je parle avec des fabricants d'outils, des innovateurs et des développeurs qui nous mènent vers un avenir sans serveur brillant.
Aujourd'hui, je parle avec Simon Wardley, consultant au Leading Edge Forum et spécialiste de la perception de la situation, des principes et du gameplay. Pour plus de commodité, j'ai édité l'interview.
C'est le degré habituel de répétabilité. Par conséquent, je dis que l'architecture sans serveur (FaaS) accélérera le développement de plusieurs ordres de grandeur. Votre système est déjà écrit à 99,9% par quelqu'un. L'astuce consiste à trouver la bonne pièce. Des conteneurs? Ne me fais pas rire. Un autre appareil maladroit. - Simon Wardley
Forrest Brazeal : Ce n'est pas votre première année en informatique et vous défendez ardemment les développements sans serveur. Cela vous intéresse depuis longtemps?
Simon Wardley : En 2005, chez Fotango, nous avons planifié l'environnement et réalisé que l'informatique se transformait en services utilitaires, ce qui signifie que les temps d'exécution du code évolueront dans la même direction.
En conséquence, nous avons créé Zimki, et en fait, c'était la première plateforme au monde en tant que service: un serveur Javascript ouvert via l'API, un véritable environnement d'exécution de code avec une facturation fonctionnelle.
Nous avons immédiatement regardé différemment le développement, la maintenance et en général du tout. Du coup, nous avons vu de nouveaux niveaux de détail en termes de coûts. Personne n'a jamais eu ça auparavant. Nous avons trouvé toutes sortes de concepts intéressants, comme le développement basé sur la valeur.
Hélas, la société mère a décidé de nous couvrir alors que nous prenions juste de l'ampleur. Mais j'y pense depuis des années. En conséquence, Lambda a surgi. À mon avis, une chose cool.
Plus raide que, disons ... des conteneurs?
Vous ne pensez pas, en fait j'adore les conteneurs. Ce sont des sous-systèmes invisibles. Mais ce n'est pas un vrai combat. La vraie chose se produit dans les exécutions de code, en particulier en ce qui concerne la facturation fonctionnelle.
Beaucoup, semble-t-il, ne reconnaissent toujours pas que l'architecture sans serveur fait tourner le monde et continuent de discuter du sens du mot. Cela vous surprend-il que cela traîne?
Cela rappelle EC2 en 2006. Sun a longtemps essayé l'informatique utilitaire, mais peu ont pris EC2 au sérieux: «Des ordures. Qui a besoin de ça? " Et ils se sont reposés longtemps.
En 2009 ou 2010, tous ces consultants en gestion ont dit quelque chose comme: "L'avenir est aux systèmes privés, AWS ne tirera pas." Avec le même succès, nous pouvons dire: "Eh bien, pour ces voitures, il vaut mieux faire le plein de foin pour les chevaux." Nous savons tous où se trouve Amazon.
Est-ce que quelqu'un les rattrapera?
Il s'agit du même opéra que le discours que les principaux fabricants d'équipement ont fait sur l'EC2 en 2008-2009. Les calculs se sont transformés en utilitaires, et tout le reste a traîné dessus. Maintenant, nous l'appelons DevOps: le développement rapide de systèmes d'ordre supérieur, des changements rapides, un équilibre intermittent.
Et les grandes entreprises roulent sur l'inertie et se consolent du fait que tout cela ne deviendra pas populaire et ne les affectera pas. Bien sûr, ils ont mal calculé.
À cette époque, les principaux fabricants d'équipement possédaient toute l'artillerie lourde. Bezos avait une Amazone et une fronde. Et il a gagné. Ce n'était pas une erreur d'ingénieurs, mais de leadership. Maintenant, ils veulent revenir au jeu, mais toute la force est du côté d'Amazon.
Avec une architecture sans serveur, la même chose se produit. Bien sûr, d'autres entreprises auraient pu se battre avec Amazon, mais ne le feraient pas, car elles n'y croyaient pas. Et quand ils croient, le train partira.
Si l'architecture sans serveur est si bonne, pourquoi tout le monde s'empare des conteneurs?
Pour utiliser Lambda, il y a beaucoup à comprendre. C'est un média complètement différent, un grand bond en avant. Les conteneurs sont plus faciles. De plus, ils sont portables, et tout cela est terriblement heureux, en particulier les fournisseurs.
Ils n'en parlent que et essaient de ne pas remarquer un changement vers les temps d'exécution du code. Les conteneurs ne forcent pas à changer l'architecture et ne montrent pas que presque tout votre code a déjà été écrit par quelqu'un.
Lambda est-il vraiment un outil si puissant qui en vaut la peine?
J'ai récemment mené une enquête sur Twitter: combien de fois les gens ont-ils réécrit les fonctionnalités d'enregistrement de base des utilisateurs. Il s'est avéré - un million.
... à titre d'exemple. Si vous développez depuis au moins 10 ans, combien de fois avez-vous réécrit la fonction d'enregistrement des utilisateurs? - Simon Wardley
C'est incroyable quel haut niveau de répétabilité dans les entreprises. Les gens pensent que les gouvernements gaspillent des ressources. Le pire cas de répétabilité que j'ai vu au gouvernement est 118 systèmes qui ont fait presque la même chose.
Dans le secteur privé, j'ai vu des banques avec mille systèmes de gestion des risques identiques. Et combien y en a-t-il partout dans le monde? Des millions et des dizaines de millions des mêmes systèmes.
Je m'excuse, mais nous passons des journées entières à recycler les vieux papiers. Et si vous changez radicalement l'architecture, vous pouvez passer ce temps sur des fonctions vraiment utiles. Mais, bien sûr, il est plus facile de dire: «Wow, container! Entre et sort - super! Et l'environnement est presque comme des pantoufles préférées. »
Ici, d'ailleurs, sur le "in and out". Beaucoup craignent que l'architecture sans serveur soit "le pire cas de liaison de fournisseur dans l'histoire humaine ". Est-ce vrai? Serons-nous totalement dépendants du fournisseur informatique sans serveur?
Bien sûr, ce serait cool si nous avions différents fournisseurs concurrents. Mais ce n'est pas aussi important que les avantages et les fonctionnalités. Les entreprises se font toujours concurrence. Et la chance que les fournisseurs soient d'accord est presque nulle. Tout le monde dit: "Nous nous distinguerons par ceci et cela."
La seule exception est, bien sûr, l'amour universel des conteneurs. Tous se précipitent avec des conteneurs, mais le champ de bataille a changé. Vous avez gagné la bataille, mais perdu la guerre.
Nous parlons beaucoup de batailles aujourd'hui. Qui gagnera et qui perdra si l'informatique sans serveur se développe selon votre scénario?
Aujourd'hui, Amazon et Alibaba, qui ont coupé la puce, gagnent. Il existe encore des entreprises très intelligentes, comme Netflix, qui utilisent ces technologies et s'adaptent rapidement.
Et, bien sûr, des entreprises d'une ou deux personnes pour un milliard de dollars apparaîtront de nulle part. Ils auront une fonction. Personne ne connaîtra ces gars, mais tout le monde utilisera cette fonctionnalité en tant que service.
Quant aux perdants ... Je ne veux pas vous déranger, mais il y aura des fans de DevOps parmi eux.
N'oubliez pas que lorsque l'informatique était un produit, nous avons construit des méthodes architecturales sur les caractéristiques de ce produit. Prenons, par exemple, un temps de récupération moyen élevé (MTTR). Nous avons élargi, planifié la capacité, pensé à la reprise après sinistre et des trucs comme ça.
Et puis les calculs sont devenus un utilitaire, le temps de récupération moyen a été réduit, et nous avons créé de nouvelles méthodes: systèmes distribués, assurance contre les pannes, ingénierie du chaos, déploiement continu. Au fil du temps, il est devenu connu sous le nom de DevOps. Les calculs en tant que produit sont obsolètes.
Maintenant, avec une architecture sans serveur, de nouveaux changements nous attendent et DevOps deviendra une relique du passé. Et ils commenceront à les oublier.
Certains n'ont même pas vraiment eu le temps de passer à DevOps.
Oui, il y a ceux qui commencent tout juste leur transition de cinq ans vers DevOps. En conséquence, ils y arriveront et il n'y a personne là-bas. C'est dommage.
À quoi ressemblera le développement logiciel dans dix ans?
Nous ne savons même pas quelles méthodes évolueront sur une architecture sans serveur. Je ne dirai pas avec certitude, mais il y a quelques suppositions.
Les développeurs s'occuperont des questions financières. Le coût de la fonction sera plus important que jamais. De nouveaux modèles de développement basés sur la valeur apparaîtront: une entreprise construira un système pour une autre, mais pas à prix fixe, mais pour une partie des bénéfices de ce système.
Bien sûr, pour cela, les entreprises elles-mêmes doivent comprendre les bénéfices que le système apporte.
La structure de l'entreprise va également changer. C'est une chose courante. L'électricité est passée d'un produit à un service public, et de nombreux systèmes d'ordre supérieur ont vu le jour. La même chose s'est produite avec la production lorsque le fordisme et le système américain sont apparus.
Lorsque cela se produit, de nouvelles méthodes apparaissent et la forme d'organisation change. Je pense que ce sera la même chose avec une architecture sans serveur.
Autrement dit, à votre avis, dans le développement de logiciels, il y aura moins de pertes et une plus grande efficacité?
Définissons les termes. Ne confondez pas les pertes avec les dépenses. Ce sont des choses différentes.
Nous verrons une efficacité élevée et un développement rapide de systèmes d'ordre supérieur. Quant aux coûts informatiques, ils ont évoqué EC2 en 2007-2008. Et bonjour le paradoxe de Jevons .
En fait, il s'avère que plus la chose est efficace, plus nous en avons besoin. Les gens pensent qu’ils économiseront des tonnes d’argent avec l’informatique sans serveur. Je dois rouler ma lèvre. Nous en prendrons juste plus.
Et la dernière question: que diriez-vous à une personne qui ne peut pas choisir entre une architecture sans serveur et des conteneurs?
[rires] Mais est-ce mon ami ou quoi?
À mon avis, nous avons plus en commun que le désaccord. Je suis plus préoccupé par le timing. La guerre éclate sur un champ de bataille sans serveur. Et toute la rhétorique devrait être là. Équilibre intermittent - c'est ça: vous pensez, attendez encore cent ans, puis vous regardez - ils ont navigué. - Simon Wardley
Disons ami.
Eh bien, laissez-le choisir ce qu'il veut si le projet est à court terme. Je ne suis pas contre les conteneurs.
Mais si le projet est long, mieux vaut ne pas prendre le temps de maîtriser l'informatique sans serveur. L'avenir leur appartient.