Je ne sais plus ce qu’est Serverless | de Allen Helton | décembre 2022

La définition du sans serveur change et personne ne semble s’accorder sur ce que c’est réellement

Vous ne vous attendriez probablement pas à ce qu’un AWS Serverless Hero dise : «Je ne sais pas ce qu’est le serverless.

Je ne suis pas fier de cette déclaration. En fait, je suis un peu vexé. J’avais l’habitude d’avoir une solide compréhension du sans serveur, mais cela semble avoir été bouleversé récemment.

De plus en plus de gens claquent le mot « sans serveur » sur leurs projets, services et dépôts, atténuant la définition que nous avions auparavant.

Sans serveur est assez dur comme ça. La mise en route nécessite un changement d’état d’esprit important par rapport à ce à quoi de nombreux développeurs sont habitués. Ajoutez à cela les dizaines de didacticiels qui vous apprennent à créer dans la console AWS, et vous avez une recette pour un mauvais moment.

Nous devons nous mettre d’accord sur ce que signifie réellement sans serveur. Pour aller plus loin, nous devons nous mettre d’accord sur ce qu’est le développement sans serveur – ce qui est une histoire complètement différente.

Lorsque je dis sans serveur, je fais généralement référence aux services que les développeurs utilisent pour créer des applications. Les exemples sont AWS Lambda, EventBridge, DynamoDB et Step Functions. Mais qu’est-ce qui les rend sans serveur par rapport à des services comme Amazone Aurore ou ECS?

Temps a un grand test décisif qui, je pense, met le doigt sur la tête pour ce qui définit un service véritablement sans serveur.

Les développeurs devraient pouvoir choisir et utiliser un service sans serveur. Pour le dire succinctement, ces services juste travailler. Pensez à la dernière fois que vous avez créé une fonction Lambda. Vous avez passé un seul appel au CreateFunction endpoint (ou de préférence l’a déclaré dans IaC), puis ont immédiatement pu commencer à l’invoquer.

Comparez cela à quelque chose comme Neptune Serverless, où je dois configurer un VPC, choisir des unités de capacité et sélectionner des paramètres de déploiement multi-AZ. On n’a pas vraiment l’impression ça marche.

Au-delà de l’expérience de développeur de services sans serveur, vous avez également un impact sur une organisation. Dans quelle mesure le service peut-il évoluer de manière élastique ? Si vous avez un trafic en rafale, l’infrastructure s’adaptera-t-elle automatiquement pour le gérer sans nécessiter une équipe SRE interne ?

Qu’en est-il lorsque l’application n’est pas utilisée ? Est-ce que ça va à zéro ? Personne ne veut payer pour des ressources surdimensionnées qui ne sont pas utilisées. Le modèle de paiement pour ce que vous utilisez sans paiement minimum est un énorme indicateur que vous utilisez un service sans serveur.

Le sans serveur est un paradigme où les consommateurs ne paient que pour ce qu’ils utilisent. Les services sont soutenus par une infrastructure fiable et évolutive qui se développe et se contracte automatiquement avec le trafic entrant, ce qui soulage complètement le consommateur. Ces services sont simples à utiliser avec une configuration minimale ou nulle pour démarrer.

Dans cet esprit, parlons un peu de ce que signifie être un développeur sans serveur.

Ceux qui utilisent des services sans serveur pour créer une application font du développement sans serveur. Mais ce n’est pas aussi simple qu’il y paraît.

Les développeurs sans serveur construisent avec un mentalité sans serveur. Cela signifie qu’ils abordent le développement en cherchant à tirer parti des avantages des services sans serveur, tels que la gestion de l’infrastructure, la disponibilité et l’évolutivité (entre autres). Cela ne signifie pas qu’ils doivent utiliser Lambda ou Step Functions pour chaque charge de travail.

Il ne s’agit pas des services spécifiques qui composent vos applications ; il s’agit des avantages que vous obtenez en tant qu’organisation lorsque vous profitez d’un modèle de responsabilité partagée.

Beaucoup d’entre nous s’enlisent dans les détails de ce qu’est le développement sans serveur. Oui, savoir comment créer des intégrations directes ou optimiser les performances en utilisant Step Functions sur Lambda est un détail important lors de la création d’une application, mais ce n’est pas ce que le développement sans serveur est à la base.

Il s’agit de se concentrer sur la satisfaction complète et efficace d’un problème commercial. Il s’agit de mettre sur le marché des logiciels stables en un temps record. Il s’agit de trouver le bon adéquation produit-marché sans se ruiner.

J’espère que certains d’entre vous hochent la tête en signe d’accord. Je sais que d’autres penseront que je suis fou et auront des opinions différentes sur ce qui est ou n’est pas sans serveur. Mais au bout du compte, est-ce vraiment important ?

Pas pour longtemps.

Le sans serveur est un tremplin vers un avenir logiciel plus rapide, plus durable et plus robuste. Comme Brisals brillants mentionné dans son Récapitulatif récent d’AWS re:Invent 2022, les concepts de base du développement sans serveur existent depuis longtemps. Les fournisseurs de cloud comme AWS facilitent leur utilisation. Mais il faut une scène mondiale pour faire passer le message que c’est ainsi que les applications modernes doivent être construites.

Ce que nous devons pousser en ce moment, c’est l’adoption non seulement du cloud, mais aussi des meilleures pratiques du cloud. Utilisez des architectures pilotées par les événements, concevez des modèles de données NoSQL et passez en mode asynchrone lorsque cela est possible.

Avec Infrastructure from Code (IfC) faisant une grande percée sur le marché du cloud, les services sans serveur sont complètement soustraits aux développeurs. Vous ne créez pas de fonctions Lambda, de files d’attente SQS ou de tables DynamoDB. Au lieu de cela, vous utilisez votre connaissance des modèles d’architecture des systèmes distribués pour créer des applications.

L’IfC est-il sans serveur ? Peut-être.

Et si nous le considérions comme quelque chose de complètement différent ? Tous ces allers-retours sur ce qui est ou n’est pas sans serveur pourraient éventuellement devenir sans objet, et nous nous référons à l’ensemble du paradigme comme développement cloud natif.

Il y a quelques années, nous avons eu des guerres de flammes légères sur Twitter à propos de Kubernetes contre le sans serveur. Aujourd’hui, nous avons des débats houleux sur ce qui est ou n’est pas sans serveur.

AWS a commencé à brouiller les lignes sur sa définition du sans serveur avec la sortie de Aurora sans serveur, Neptune sans serveuret OpenSearch sans serveur.

Mais peut-être que cela fait partie du voyage vers le cloud dans lequel nous sommes. Peut-être que « sans serveur » n’est plus ce qu’il était.

Les développeurs sans serveur vont se transformer en développeurs « cloud natifs ». Nous concevrons des logiciels qui s’appuient sur des modèles architecturaux établis et ne reposent pas fortement sur des services gérés spécifiques.

Il y a beaucoup de mouvement dans notre industrie en ce moment. Beaucoup d’opinions, beaucoup de logiciels, beaucoup d’idées. Tout change si vite; il ne devrait pas être surprenant que nous nous efforcions de redéfinir le sans serveur.

Chaque fois que nous atterrissons enfin sur quelque chose, ce n’est qu’une question de temps avant que cela ne change à nouveau.

Bon codage !