Oleksandr - Fotolia
Serverless : les bons cas d’usage
Les architectures et les développeurs ont été lents à détecter les bons cas d’usage du serverless. Mais cela s’accélère. L’adoption devrait suivre. Cet article détaille certains cas d’utilisation précis.
Quelles workloads sont faites pour une architecture serverless ? Théoriquement, toute application peut fonctionner sur ce modèle. Toutefois, dans un souci d’efficacité et de RoI, les responsables des architectures doivent identifier les bons scénarios d’utilisation, ceux qui ont la capacité d’optimiser réellement le serverless.
Les exemples ci-dessous, qu'ils soient établis ou émergents, ont de quoi intéresser les architectes et les développeurs à la recherche des précieux RoI pour justifier leurs projets.
Applications bâties sur des événements
AWS a été l’un des pionniers dans l'architecture serverless avec Lambda en 2014, ciblant à l’époque les workloads qui reposent sur des événements. Lambda peut faire appel à de petites fonctions de code et les exécuter lorsqu'un événement se produit dans une zone différente. Par exemple, l'événement peut nécessiter la mise à jour d'une base de données Amazon DynamoDB. L'appel génère une instance du code présentant une latence extrêmement faible, qui exécute l'action requise. Ensuite, Lambda le supprime pour optimiser l'utilisation des ressources. Il s'agit du cas d'utilisation du serverless avec lequel les développeurs sont le plus familiarisés.
Lorsque Lambda a fait ses débuts, les possibilités d'utiliser cette approche étaient limitées. Les développeurs ont alors préféré créer l'intégralité de la base de code sur la plateforme IaaS d’AWS plutôt que de scinder le code entre deux environnements différents. Cependant, avec l’option gratuite de Lambda, les développeurs ont commencé à tester le service. Cette phase initiale a jeté les bases d'une utilisation du serverless et des offres concurrentielles ont alors émergé: Google Cloud Functions, Microsoft Azure Functions, le projet open source Fn et IBM Cloud Functions qui s’adosse à Apache OpenWhisk.
Les microservices et des architectures serverless peuvent aussi être utilisés pour exécuter des workloads qui auraient été jugées trop chères ou inadaptées à une conception monolithique sur des ressources réservées. Cependant, le serverless n'est pas un remplaçant d’autres modes de fonctionnement. Les meilleurs projets de ce modèle exploitent des workloads basées sur des événements et non celles où l’exécution est constante.
Transfert de données
L'un des cas d'utilisation du serverless est de créer une architecture qui évite d’avoir recours à un système de gestion de contenu et d'un réseau de distribution de contenu. À la place, les événements sont déclenchés et prennent un objet S3 (Amazon Simple Storage Service) directement à partir du système de gestion de base de données dans le back-end de l'application et le présentent à un utilisateur.
Une autre possibilité consiste à utiliser une architecture serverless pour un ETL (Extract, Transform, Load). Seules les ressources nécessaires sont utilisées pour exécuter les événements ETL et réduire les coûts.
Le serverless au sein d'un workflow avec IA
L'analyse de la vidéo et des images est un autre cas d’usage pour le serverless, plus complet. Dans cet exemple, cette architecture permet de créer un workflow à la demande et un déclencheur d’événement active un service IA : les images sont capturées et analysées sur un environnement IaaS standard mais les événements déclenchent Amazon Rekognition ou un service similaire pour effectuer la reconnaissance faciale en cas de besoin. Le New York Times a utilisé cette méthode pour créer son système de reconnaissance faciale à partie des caméras publiques autour du Bryant Park à New York.
Autre cas d’usage : la mise en application des politiques de sécurité. A partir de triggers, les logs des évènements, de n'importe quel périphérique, envoient une commande dans un environnement serverless. Le code est lancé pour identifier la cause première de l'événement issu des logs ou démarre une analyse de la situation sur le périphérique, grâce au Machine Learning. Ces informations, à leur tour, peuvent déclencher certaines étapes pour résoudre les problèmes et protéger l'ensemble des systèmes.
Le serverless pour l'IoT
L’IoT est aussi un environnement qui peut bénéficier du serverless. À mesure que le nombre de périphériques connectés à un réseau augmente et que chaque périphérique crée des données, il faut gérer ces données. Cela peut justement reposer sur des événements.
La grande majorité des terminaux IoT ne contiennent pas d’intelligence interne. Par conséquent, une architecture serverless capable d'agréger les données de plusieurs périphériques, d'analyser leurs données puis de déclencher les bons événements constitue une méthode peu coûteuse mais hautement fonctionnelle pour gérer ce type de dispositif IoT.
A l'origine, le serverless n’avait pas de vrai problème à résoudre. Mais des cas d’usage utiles commencent à émerger. Ce n’est donc qu’un début. Cette architecture a tout pour se mêler aux microservices.