Serverless : pourquoi faut-il migrer ses applications ?
Publié par La rédaction le | Mis à jour le
Ce sera, sans nul doute, la mission numéro un des DSI pour ces prochaines années : le modèle serverless s’impose comme étant le plus adapté pour exploiter les ressources du cloud public sans faire exploser sa facture. Le vaste chantier de migration des applications est lancé !
Après la virtualisation, puis le « move to cloud », la conteneurisation des applications, le serverless est sans doute la prochaine étape de la dématérialisation des infrastructures informatiques. En tout cas, il est désormais au cœur de la modernisation des applications.
« La définition du serverless, c’est de ne plus avoir d’instance serveur ou d’infrastructure à gérer, avec un paiement à l’usage », résume Sébastien Stormacq, Principal Développer Advocate chez AWS (Amazon Web Services).
« Le serverless offre évidemment la capacité de monter en charge automatiquement, mais aussi de réduire l’infrastructure jusqu’à zéro, lorsque celle-ci n’est pas sollicitée. C’est une capacité de « scale to zero » que n’offrent pas les machines virtuelles, car on continue à payer pour celle-ci, même si aucune application ne tourne, et ce tant qu’elle n’est pas décommissionnée. »
Ce n’est pas un hasard si Veolia, l’entreprise du CAC40 la plus avancée dans sa stratégie de « move to cloud », s’est très rapidement intéressée à AWS Lambda dans une logique FinOps.
Le géant de l’environnement a mis en place une série de fonctions Lambda pour traquer les ressources EC2, EBS, RDS, ELB et S3 inutilisées dans son infrastructure.
Finops, puissant moteur pour le serverless
Si les fonctions Lambda d’AWS et ses équivalents Azure Functions et Cloud Functions de Google ont permis, dans un premier temps, de créer des petites fonctions orientées DevOps, leurs capacités se sont nettement accrues ces dernières années.
Et chaque cloud provider propose maintenant tout un écosystème de solutions qui favorisent la conception d’applications serverless de plus en plus ambitieuses. « Comme pour de nombreux services que nous lançons, nous avions pensé à un usage et nos clients en ont trouvé d’autres », commente Sébastien Stormacq. « Nous avons imaginé, à l’origine, le serverless pour faire tourner du code en réponse à des événements et gérer ainsi automatiquement l’infrastructure. Le nombre et la nature des événements se sont élargis. Il est devenu possible de faire des appels d’API externes depuis Lambda et ainsi d’ouvrir le serverless à toutes les applications. »
Depuis son lancement en 2014, de plus en plus de langages sont disponibles pour AWS Lambda et, il y a deux ans, l’Américain a implémenté la fonction de « custom runtime » qui permet de faire tourner n’importe quel workload compatible Linux en serverless.
En parallèle, tous les fournisseurs de services cloud ont accru la puissance de calcul disponible pour les fonctions serverless, augmenté le temps de traitement maximal et introduit des capacités de démarrage à froid plus performantes, autant d’améliorations qui ont rendu ces fonctions utilisables dans un nombre de cas d’usage bien plus larges.
La nouvelle version de Cloud Functions, de Google, permet d’allouer 16 Go de RAM et quatre processeurs virtuels à Cloud Functions, un temps de traitement de 60 minutes maximum et jusqu’à 1 000 requêtes simultanées… de quoi satisfaire différents de besoins applicatifs !
Orchestrer les enchaînements de fonctions
Outre l’exécution de services, les offres serverless des hyperscalers se sont très largement étendues et il est aujourd’hui possible de créer des architectures extrêmement complexes en quasi 100 % serverless. Si on prend le catalogue serverless de Microsoft Azure, on y trouve de multiples solutions.
Dans le domaine du calcul, outre Azure Functions, Microsoft propose Kubernetes Serverless pour combiner une approche conteneurs au serverless. Des outils orchestration (Azure Logic Apps) et de bus d’événement Event Grid permettent d’orchestrer des enchainements de fonctions serverless et ainsi de créer des applications bien plus évoluées qu’un simple déclenchement de fonction.
Même les bases de données qui doivent pourtant assurer la persistance des données dans ces nouvelles architectures connaissent cette vague du serverless.
Microsoft a décliné son SGBD managé Azure SQL Database en version serverless. L’idée n’est évidemment pas de créer, puis de détruire la base de données à chaque appel, mais de bénéficier d’une facturation à l’usage, à la seconde, avec la possibilité de placer la base de données en pause et ne payer alors que le stockage.
Chaque hyperscaler cherche à favoriser au maximum l’intégration de ses services aux architectures serverless de ses clients. Connexion aux passerelles d’API, génération d’événements par chacune de ses solutions, le degré d’intégration de l’application peut être très avancé, avec un risque évident de « vendor lock-in » pour l’entreprise qui fait ce choix.
Sites transactionnels, applications Big Data/IA, IoT, quasiment plus aucun domaine ne pourra échapper à cette nouvelle révolution dans les architectures distribuées.