La fonction en tant que service (FaaS) trouve rapidement une utilisation dans une variété de contextes opérationnels et de développement.
Bien que l’étoile montante du cloud computing soit souvent mentionnée en conjonction avec les API, l’IoT et les applications mobiles, cette technologie est largement utilisée en dehors du développement. Dans le rapport « Guide to Serverless » de The New Stack, nous constatons que les cas d'utilisation technique du sans serveur couvrent un ensemble robuste d'utilisations :
Cas d'utilisation technique pour Serverless
Comme prévu, les applications dominent la scène avec près des trois quarts des répondants utilisant le sans serveur pour les API REST et les applications Web. Mais après cela, cela devient plus intéressant. Les tâches par lots et les tâches planifiées, ainsi que la nébuleuse « logique métier », recueillent toujours plus de la moitié des cas d'utilisation des répondants.
L'utilisation de fonctions cloud pour gérer les actifs cloud fait partie du domaine des « tâches planifiées ». L’une des capacités que le cloud et les conteneurs offrent aux entreprises est la possibilité d’optimiser l’utilisation des ressources. Nous pensons généralement à cela en termes d’évolutivité, en particulier lorsqu’il est associé à des conteneurs et des microservices. En mettant à l’échelle uniquement les éléments d’une application qui nécessitent une mise à l’échelle, vous économisez des ressources de calcul (et donc des coûts).
Mais l’autre côté de cette équation est la capacité de fermer les ressources lorsqu’elles ne sont pas utilisées. L'attrait, en partie, de la fonction en tant que service et sans serveur (non, ce n'est pas nécessairement la même chose) réside dans le véritable modèle de tarification des services publics. Vous ne payez réellement que ce que vous utilisez. Étant donné qu’idéalement, il n’y a pas de ressources inutilisées dans un environnement sans serveur/FaaS, vous ne payez pas pour elles. Dans le cloud, en revanche, vous payez peut-être pour des ressources inactives au même prix que si ces ressources exécutaient une application ou un service. C'est un problème mineur, mais qui peut s'accumuler si vous avez beaucoup de temps d'arrêt pour une application.
C'est là que les fonctions cloud peuvent aider. En tirant parti des fonctionnalités de fonction en tant que service du cloud dans lequel vous exécutez, vous pouvez planifier une tâche pour arrêter les instances lorsqu'elles ne sont pas utilisées et les redémarrer ultérieurement. Cela suppose un planning assez statique, comme une application qui n'est utilisée que pendant une journée de travail bien définie. Ces applications sont souvent des applications « professionnelles » traditionnelles qui sont utilisées par les employés mais uniquement pendant la journée – et la semaine de travail. La fermeture des instances qui composent une application professionnelle pendant le week-end peut permettre de réaliser des économies considérables au fil du temps.
L'utilisation de la fonction en tant qu'offre de service de votre fournisseur de cloud peut vous permettre de réduire le coût de maintien de ces applications « au chaud » pendant la nuit et le week-end. Même si vous envisagez une journée de travail de douze heures, vous pourriez réduire vos coûts de moitié en fermant vos magasins pendant les douze autres heures.
Si vous êtes curieux de savoir comment implémenter ce qui me semble être une version cloud de cron, consultez ces ressources :