Le serverless promet d'aller plus loin dans le lissage des coûts du cloud

Comment ? Vous n’avez pas encore entendu parler du serverless ? Le nouveau sujet à la mode dans le monde de l’architecture logicielle ? Alors vous avez été épargné par quantité de livres, de frameworks open source et de produits vantés par des fournisseurs enthousiastes. Tant mieux. Prenez quelques minutes pour comprendre concrètement ce dont il s’agit.

Qu’est ce que le Serverless ?

Le terme ‘serverless’ a été d’abord utilisé pour décrire des applications informatiques qui dépendent pour tout ou en grande partie d’applications et de services qui fonctionnent en mode cloud. Ce sont généralement des applications de type « client riche », c’est à dire des pages web, ou des applications mobiles qui utilisent de grands écosystèmes de bases de données accessibles en mode cloud, comme Parse ou Firebase ), des services d’authentification comme Auth0 ou AWS Cognito , et d’autres briques fonctionnelles conçues et gérées en mode cloud. Bref, de quoi se doter d’un véritable ‘Backend as a Service’. « Amazon Cognito vous permet d’ajouter facilement l’inscription et la connexion d’utilisateurs à vos applications mobiles et web » mentionne Amazon sur le site dédié de cette offre.

Mais le terme serverless définit aussi désormais des applications dont une partie du code est exécutée dans des conteneurs indépendants fournis par des tiers. Cette configuration répond en un sens à une logique de FaaS, ou ‘Functions as a service’. AWS Lambda est, à titre d’exemple, un des ces services. « AWS Lambda est un service de calcul sans serveur qui exécute votre code en réponse à des événements et gère automatiquement les ressources de calcul sous-jacentes pour vous » précise Amazon sur son site Web. « AWS Lambda peut exécuter automatiquement un code en réponse à plusieurs événements, tels que les modifications d’objets dans des buckets (compartiments) Amazon S3 ou les mises à jour de tables dans Amazon DynamoDB ».

Vers une facturation à l’usage composant logiciel par composant logiciel

Si le BaaS est de plus en plus connu, ne serait ce que par la démocratisation des services de cloud computing, le FaaS est nettement moins populaire. Reste que les deux concepts convergent. Le service Auth0 propose par exemple désormais les deux cas d’usage. Dans les deux cas, ce sont des plates-forme de PaaS qui permettent d’architecturer ces solutions. Et dans le cas spécifique du serverless, la technicité repose sur la capacité à assembler les services pour composer une application. Ce sont donc des critères fonctionnels et des critères de performance qui devront être établis par les utilisateurs.

Cela signifie aussi que le modèle de tarification de ces applications passe par la facturation à la transaction ou à l’exécution d’un composant. Là aussi une granularité de plus en plus importante peut voir le jour : le fonctionnement d’une application, et sa facturation, va dépendre de plusieurs composants. En fonction de ce qui est demandé à l’application, elle va utiliser différents composants, et chacun des composants va être facturé indépendamment. Si un composant n’est jamais utilisé, il n’est jamais facturé.

Côté production, passer au NoOps avec le serverless

Une équipe de DevOps gère une grande variété de tâches allant de l’approvisionnement, la gestion des versions, leur intégration, leur déploiement et leur suivi. Le serverless offre la plupart de ses fonctions et des outils tels que Jenkins peuvent être facilement intégrés à ces environnements sans serveur pour déployer le code juste après chaque validation. Et comme le système d’exploitation et l’exécution sont gérées par la plate-forme du fournisseur, il n’y a patcher ou à mettre à jour. C’est ce que l’on appelle le NoOps. Et cela peut peser considérablement dans la balance des coûts de maintenance de la DSI.

Pour aller plus loin sur ce sujet :

Go to Source