Économiser du temps et de l'argent avec le serverless (2e partie)

Pour lire la 1e partie de ce sujet, cliquer sur ce lien

Fournisseurs serverless : AWS Lambda, Azure Functions et Google Cloud Functions

L'ère moderne de l'informatique serverless a débuté avec le lancement, en 2014, d'AWS Lambda, une plate-forme basée sur le service cloud d'Amazon. Microsoft a fait de même en 2016 en lançant Azure Functions. Google Cloud Functions, en bêta depuis 2017, a finalement atteint le statut de production en juillet 2018. Les trois services ont des limitations, des avantages, supportent des langages et leurs modalités sont légèrement différentes. Rohit Akiwatkar connaît bien les différences entre ces trois services. Il faut ajouter à cette liste IBM Cloud Functions, basé sur la plate-forme open source Apache OpenWhisk. Parmi toutes les plates-formes serverless, AWS Lambda est la plus importante, et c’est elle qui a eu le plus de temps pour évoluer et mûrir.

Piles serverless

Comme c'est le cas dans de nombreux domaines du software, le monde serverless a vu évoluer les piles logicielles qui rassemblent les différents composants nécessaires pour construire une application serverless. Chaque pile se compose d'un langage de programmation dans lequel on écrit le code, d'un framework d'application qui fournit une structure pour le code et d'un ensemble de déclencheurs que la plate-forme comprendra et utilisera pour lancer l'exécution du code. Même s’il est possible de combiner différentes offres spécifiques dans chacune de ces catégories, il existe des limitations en fonction du fournisseur, avec un certain chevauchement. Par exemple, pour les langages de programmation, il est possible d’utiliser Node.js, Java, Go, C# et Python sur AWS Lambda, mais seuls JavaScript, C# et F# travaillent nativement sur Azure Functions. Pour ce qui est des déclencheurs, c’est AWS Lambda qui affiche la liste la plus longue, mais beaucoup d'entre eux sont spécifiques à la plate-forme AWS, comme Amazon Simple Email Service et AWS CodeCommit. De son côté, Google Cloud Functions peut être déclenché par des requêtes HTTP génériques.

Frameworks serverless

Selon Paul Jaworski, qui connaît bien les piles de chacune des trois grandes offres, cela vaut la peine de s'attarder un peu sur la partie framework, car elle définira en grande partie la façon dont vous construirez votre application. Amazon dispose de sa propre offre native open source Serverless Application Model (SAM), mais il en existe d'autres, dont la plupart sont multiplateformes et également open source. L'une des plus populaires est appelée, de manière assez générique, Serverless, pour souligner qu'elle offre la même expérience qu'une plate-forme supportée, c'est-à-dire AWS Lambda, Azure Functions, Google Cloud Functions, et IBM OpenWhisk. Apex est une autre offre populaire qui permet de faire entrer certains langages qui ne sont pas disponibles chez certains fournisseurs.

Bases de données serverless

Comme nous l'avons mentionné plus haut, une particularité du travail avec du code serverless, c’est qu'il n'a pas d'état persistant, ce qui signifie que les valeurs des variables locales ne persistent pas entre les instanciations. Toutes les données persistantes auxquelles votre code doit accéder doivent être stockées ailleurs, et les déclencheurs disponibles dans les piles des principaux fournisseurs comprennent tous des bases de données avec lesquelles vos fonctions peuvent interagir. Certaines de ces bases de données sont elles-mêmes désignées comme « serverless ». Cela signifie qu'elles se comportent comme les autres fonctions serverless dont nous avons parlé précédemment, à l'exception évidente que les données sont stockées indéfiniment. Mais une grande partie des tâches de gestion liées à l'approvisionnement et à la maintenance d'une base de données est évitée. Comme le dit le développeur Jeremy Daly : « Tout ce que vous avez à faire est de configurer un cluster, puis toutes les opérations de maintenance, correctifs, sauvegardes, réplication et mise à l'échelle sont traitées automatiquement pour votre compte ». Comme pour les offres de fonction-en-tant-que-service, vous ne payez que pour le temps de calcul que vous utilisez réellement, et les ressources sont réparties de haut en bas selon les besoins pour répondre à la demande. Les trois grands fournisseurs de services serverless proposent chacun leurs propres bases de données serverless : Aurora Serverless et DynamoDB pour Amazon, Azure Cosmos DB pour Microsoft, et Cloud Firestore pour Google. Mais ce ne sont pas les seules bases de données disponibles, comme le signale Nemanja Novkovic.

Informatique serverless et Kubernetes

Les conteneurs aident à alimenter la technologie serverless sous le capot, mais les tâches de gestion sont prise en charge par le fournisseur et donc invisibles pour l'utilisateur. Beaucoup pensent que l'informatique serverless permet profiter des nombreux avantages des microservices conteneurisés en gommant leur complexité, évoquant même un monde post-container. En réalité, les conteneurs et l'informatique serverless vont certainement continuer à coexister pendant de nombreuses années encore. En fait, les fonctions serverless peuvent exister dans la même application que les microservices conteneurisés. Kubernetes, la plate-forme d'orchestration de conteneurs la plus populaire, est également capable de gérer une infrastructure serverless. En effet, avec Kubernetes, vous pouvez intégrer différents types de services sur un même cluster.

Du serverless hors ligne

La perspective d’utiliser une informatique serverless sans serveur peut paraître intimidante au départ, car elle laisse entendre qu’il faut s’abonner à un fournisseur de service pour voir comment cela fonctionne. Mais ce n’est pas le cas : vous pouvez exécuter du code serverless hors ligne sur votre propre matériel local. Par exemple, le SAM AWS fournit une fonction locale qui permet de tester le code Lambda hors ligne. Et si vous utilisez le framework d'application Serverless, regardez du côté du plug-in serverless-offline, qui permet d'exécuter du code localement !