Dans cet article, je ne vais pas définir ce qu'est le serverless. Je ne m'étendrai même pas sur les avantages économiques et architecturaux du sans serveur dont nous avons tous entendu parler : réduction des opérations d'infrastructure, mise à l'échelle instantanée axée sur les événements et faibles coûts.
Au lieu de cela, je veux expliquer pourquoi le sans serveur est la chose dont tous les développeurs devraient se soucier, que leurs patrons s'en soucient ou non, ENCORE.
A commencer par une histoire personnelle, bien sûr…
Je n'ai jamais fait de "développement web". Les guillemets doubles ici ne sont pas destinés à se moquer du concept mais à signifier mon ignorance de ce que cela signifie. Je ne connaissais pas la différence entre un service, un niveau, Apache, IIS, ASP, JSP, JS, CSS ou d'autres acronymes depuis très longtemps. En tant que développeur de logiciels, j'avais soit écrit des applications de bureau en code C++ pour Windows, soit des applications de gestion de serveur en code C pour Linux. J'ai toujours pensé que c'était ce que les enfants cool devaient faire et que tous les "trucs du Web" étaient réservés aux programmeurs moins expérimentés.
Plus je m'éloignais du web, plus il devenait énigmatique pour moi. Des choses comme REST, JSON, WebAPI, etc., apparaissaient dans chaque deuxième article Internet. Les personnes qui construisaient des applications mobiles parlaient de créer des "backends de services Web" pour leurs applications, ce qui m'a dérouté. Cela n'a pas aidé que la prochaine chose la plus en vogue de la ville - "le cloud" - ait emprunté presque toutes ses caractéristiques aux "trucs du Web". Si vous vouliez créer des applications dans "le cloud", vous deviez soit très bien comprendre les "trucs du Web", soit être au fait des machines virtuelles, des conteneurs et d'autres technologies liées à la virtualisation. Je les avais évités tous les deux assez longtemps pour qu'ils aient acquis une certaine aura dans mon esprit jusqu'à ce que je décroche un emploi où j'ai été forcé d'apprendre tout cela. HEUREUSEMENT!
Mais qu'est-ce que tout cela a à voir avec Serverless ?
Beaucoup.
Je suis sûr que malgré la popularité massive du "développement Web", il existe une armée de développeurs dans le monde entier qui créent des logiciels pour les ordinateurs de bureau, les serveurs, les appareils embarqués, les appareils mobiles, etc. et ne traitent jamais beaucoup des aspects "Web" (un peu comme moi ). Beaucoup d'entre eux sont sans aucun doute inquiets à propos du "cloud" et de ce qu'il signifie pour eux - qu'il s'agisse d'avoir des compétences employables pour l'avenir ou de trouver comment connecter/transférer leurs applications existantes vers le cloud (après avoir vu les notes d'entreprise à cet effet déjà).
Ces développeurs peuvent se réjouir du fait que tout ce dont ils ont besoin pour faire fonctionner des applications dans « le cloud » est simplement d'écrire leur logique métier. Avant sans serveur, leur transition aurait peut-être signifié l'apprentissage de nombreuses technologies qui étaient toutes de nature logistique, la plupart du temps ne faisant que le gros du travail indifférencié. Avec le serverless, leurs compétences en programmation sont tout ce dont ils ont besoin. Quel programmeur n'aime pas la perspective de se concentrer uniquement sur la programmation ?
Dans le monde du bureau, créer de petites applications de console ou des utilitaires de ligne de commande pour tester une théorie ou une idée est une tâche quotidienne. Dans "le cloud", cependant, la procédure d'accompagnement consistant à essayer de prototyper une idée très basique est parfois pleine de plusieurs points de friction - configurations, configurations, SDK, intégrations, etc. Serverless réduit considérablement cette douleur pour les développeurs en gérant une grande partie de cette procédure dans les coulisses. Le prototypage facile, l'expérimentation rapide, l'apprentissage des erreurs et le pivotement basé sur les leçons sont les principes clés du développement de logiciels modernes. Une qualité très sous-estimée du sans serveur est sa capacité à fournir exactement cela.
Au début de ma carrière, le syndrome du cool-kid que j'ai mentionné précédemment (celui qui m'a éloigné des «trucs Web») m'a également éloigné trop longtemps de Visual Studio. J'ai persisté avec vim et gdb sous Linux, même lorsque tout le code sur lequel j'ai travaillé était du code C/C++ multiplateforme qui pouvait être facilement géré dans Visual Studio sous Windows. Tout cela, juste parce que c'était cool de dissoudre tout ce qui n'était pas en ligne de commande. Je ne veux pas lancer un débat sur ce sujet, mais il suffit de dire qu'au moins j'ai senti que j'avais perdu d'innombrables heures de productivité en faisant cela.
Le point le plus important que j'essaie de faire valoir ici est que les technologies concurrentes, même dans le cloud, vous permettent de faire des choses similaires. Il existe plusieurs scénarios dans lesquels des machines virtuelles, des conteneurs ou sans serveur fourniront des sorties similaires. Cependant, le serverless sera probablement le seul qui optimise la productivité des développeurs en offrant une expérience centrée sur la devise d'un développeur - pas de machines virtuelles, de conteneurs, d'orchestrateurs ou d'instances, mais CODE. Le problème de la gestion productive du code (même le code destiné au cloud) a été résolu par des IDE de classe mondiale comme Visual Studio.
Le serverless est-il une panacée ? Non. Y a-t-il des problèmes ? Bien sûr. Nous avons tous entendu parler de démarrage à froid, d'absence d'état, de limites de durée, de mémoire, etc. Sont-ils des facteurs décisifs ? Dans la plupart des cas, non. Les gains de productivité l'emportent déjà sur ces problèmes. Ces problèmes sont-ils insurmontables ? Pas du tout. Les fournisseurs de cloud ont vu suffisamment de mérites et de promesses dans cette technologie pour être suffisamment motivés pour résoudre ces problèmes rapidement.
En résumé, le serverless présente un excellent outil que tous les développeurs doivent avoir dans leur boîte à outils.