Bienvenue dans l'ère des applications sans serveur. Marcel Panse et Sander Nagtegaal, les fondateurs de la startup Teletext.io qui propose une plate-forme de gestion de contenu en tant que service, ont des règles de fonctionnement originales : ils interdisent à leurs développeurs d’utiliser des serveurs ou des machines virtuelles. Au lieu d'utiliser du matériel sur site ou de provisionner des machines virtuelles de type Elastic Compute Cloud (EC2) d'Amazon Web Services, ils ont décidé d’adopter la tendance en cours dans le monde du développement d'applications : construire des apps sans serveur avec Lambda d'AWS.

Les VM, des machines à problèmes ?

La tendance des apps sans serveur pourrait « changer complètement la donne en matière de développement et de déploiement d’applications », a déclaré Donnie Berkholz, analyste du cabinet 451 Research, qui suit le marché du développement d'applications. « Une grande partie de ce mouvement a été déclenché par le lancement de Lambda par AWS en 2014 », a expliqué Donnie Berkholz. Ce nouveau modèle de développement d'applications pourrait avoir un impact profond sur les professionnels de l’infrastructure et des opérations. En fait, tous les opérationnels pourraient ne plus avoir à provisionner d'infrastructure, ou même d’avoir à gérer des machines virtuelles et les systèmes d'exploitation tournant sur ces VM. Le nouveau modèle DevOps donne aux codeurs un contrôle quasi total sur la construction et la gestion du cycle de vie d'une application, depuis son développement jusqu’à sa gestion en production.

L'équipe de Teletext.io a présenté son approche dans un message posté sur le site HighScalability.com où elle liste les inconvénients des serveurs et des machines virtuelles. D’abord, selon Teletext.io, il est nécessaire d’avoir au moins un serveur ou une VM toujours active pour servir le trafic ou le trafic entrant potentiel ; il faut en plus maintenir le logiciel serveur et les systèmes d'exploitation ; par ailleurs, la mise à l'échelle n’est pas commode - démarrer une autre VM complète pour accroître la capacité de calcul est parfois surdimensionné. Au contraire, Teletext.io permet aux développeurs de modifier le code en production. Par exemple, la plateforme pourrait permettre à un développeur de modifier le code HTML à travers une interface graphique manipuler le code en back-end. (L’image ci-dessous montre comment fonctionne Teletext.io)

Un serveur ? À quoi bon ?

Marcel Panse et Sander Nagtegaal ont également fixé quelques principes de base pour leur service : il ne doit jamais tomber en panne et il doit être très rapide. À une autre époque, ils auraient peut-être utilisé les services EC2 d’AWS, ses instances VM pour héberger le code, Elastic Load Balancers pour répartir la charge, et un service de base de données relationnelle pour stocker les données. À la place, ils ont mis au point une approche basée sur une architecture sans serveurs, et des microservices gérés par API. Pour cela, ils utilisent trois produits : API Gateway d’AWS (qui gère les appels d'API entrants et les convertit en d'autres tâches AWS) ; AWS Lambda (la plate-forme de calcul basée sur les évènements qui exécute les actions en cas de besoin) ; et DynamoDB (la base de données-as-a-service NoSQL d’AWS).

Pour exécuter ses apps, Teletext.io importe sur AWS du code comme celui-ci (agrandir l'image).

Lambda, l'un des nouveaux services d’AWS, est l’élément clef de cette architecture. Les développeurs téléchargent leur code sur Lambda et le système s’occupe des fonctions. On peut comparer cela à l'application populaire « If This Then That » (ITTT). Dans les deux systèmes, un événement déclenche des actions. Par exemple, ITTT peut enregistrer automatiquement une photo prise sur votre téléphone dans DropBox. Ou ITTT peut enregistrer automatiquement toute mise à jour de Twitter dans un document Google Drive. Lambda et ITTT ne sont pas liés, mais ils fonctionnent de manière similaire. Lambda peut convertir automatiquement une image téléchargée dans Simple Storage Service d'AWS (S3) et la redimensionner. Ou encore, Lambda peut prendre automatiquement une information téléchargée dans une base de données et la transférer vers un outil d'analyse.

L'entreprise ne paie que pour les fonctions exécutées

À son niveau le plus élémentaire, Marcel Panse et Sander Nagtegaal ont programmé Lambda de telle sorte que, quand un client Teletext.io effectue une action, un appel d'API est transmis à AWS. API Gateway déclenche une fonction Lambda et Lambda s’intègre avec DynamoDB pour récupérer des données stockées qui vont servir à exécuter la demande de l'utilisateur. Selon la startup, cette architecture sans serveur présente plusieurs avantages. Les fonctions ne sont exécutées qu’à la demande. Il n’y a donc pas de risque de panne des machines ou des serveurs virtuels. « Lambda est activé uniquement quand c’est nécessaire. Et une fonction inactive ne peut pas défaillir ».

Enfin, l'entreprise ne paie que pour les fonctions exécutées. Les coûts de Teletext.io sont directement liés au nombre de clients qui utilisent le service. Si aucun client n’utilise le service, Teletext.io ne paye pas pour les fonctions Lambda qui seront exécutées ou les futurs appels d’API. La seule activité qui est facturée de manière continue, c’est le stockage de données dans DynamoDB.