
Julien Corioland
Software Developer Engineer chez Microsoft
Le Serverless est parfois présenté comme l’avenir du cloud. À raison ? Disons plutôt que c’est une autre manière de consommer et facturer les ressources du cloud. Et, quitte à parler d’évolution, je considère davantage le Serverless comme une évolution du PaaS (Plateform-as-a-Service). Une manière de pousser plus loin l’abstraction de l’infrastructure.
Comment peut-on caractériser le serverless ?
A minima, avec 4 traits distinctifs :
- Avec le Serverless, les infrastructures « disparaissent ». Fondamentalement, on active du code sans avoir à se soucier de l’infrastructure et de son dimensionnement.
- Autre point distinctif : le provisionning. Avec le Serverless, il est dynamique. L’utilisateur n’a donc pas à évaluer son besoin et à dimensionner les ressources requises. C’est la plateforme qui active selon l’usage ce qui s’avère nécessaire.
- Le troisième point représente sans doute le principal intérêt du Serverless : la facturation s’effectue au temps d’exécution. Concrètement, si une application est utilisée 30 minutes par jour, la facturation correspond aux ressources exploitées durant ces 30 minutes.
- Dernier point, le Serveless est généralement « event driven ». En clair, la fonction est activée en fonction d’un événement déclencheur (webhooks, message dans une file d’attente ou un bus…).
Dans Azure, comment est mis en œuvre le Serverless ?
Azure Functions est l’une des briques d’Azure à être totalement Serverless. Avec elle, le développeur fournit le code d’une fonction qui, une fois un événement survenu, s’exécute sans avoir donc à se soucier de l’infrastructure. On peut aussi évoquer Azure Containers Instance (ACI) qui opère dans le même esprit mais sur la base d’une image de conteneur.
Enfin, Azure Logic Apps ou encore Azure ML peuvent aussi être considérés comme des plateformes Serverless puisque leur mode de facturation s’inscrit totalement dans cet esprit. Concrètement, l’utilisateur ne provisionne pas lui-même une infrastructure dédiée à leur exécution
À quels usages se destine finalement cette approche ?
Le serverless est bien adapté à du code qui s’exécute en réaction à un événement qui survient de manière peu fréquente. Y recourir pour des applications plus « permanentes » ne permettra pas de s’y retrouver. L’intérêt du Serverless est ailleurs, dans sa capacité à exécuter du code activé par intermittence avec un coût très maîtrisé et en faisant abstraction totale de l’infrastructure.