Fermer
Entrez votre texte ici
samiadrici-cloud-architecture-serverless

Serverless

Serverless 800 400 Samia Drici

Home >> Cloud Computing >> Serverless

L’architecture serverless est un modèle dans lequel le cloud provider est responsable de l’exécution d’un morceau de code en allouant les ressources de manière dynamique. Le code prend généralement la forme d’une fonction et dans ce cas, le serverless est également appelé FaaS : Functions as a Service.

Initiée en 2014, l’architecture serverless se dessine comme la nouvelle étape du cloud computing. Une évolution de l’architecture en microservices dans laquelle l’application est découpée en fonctions qui détiennent chacune une responsabilité précise.

Le code correspondant à chaque fonction est exécuté dans des conteneurs stateless par le cloud provider, et déclenché par un événement. Une requête http, un événement de base de données, un service de file d’attente, une alerte de surveillance, un téléchargement de fichiers, ou encore une tâche cron sont autant d’événements qui peuvent déclencher l’exécution d’une fonction. On parle de fonctionnement event-driven.

Les avantages du serverless

Autoscaling et optimisation des coûts d’exploitation

Vous ne payez que la quantité de ressources utilisées pour exécuter le code. La différence opérationnelle clé entre FaaS et PaaS est la mise à l’échelle. Même si vous configurez votre application PaaS à l’échelle automatique, vous ne pouvez pas le faire au niveau des demandes individuelles et donc une application FaaS est beaucoup plus intéressante en matière de coûts.

Réduction des coûts de développement

Les développeurs se concentrent uniquement sur la fonction attendue, sans se soucier de la supervision, du load balancing, de la puissance, du stockage…

Réduction du Time To Market et gain de compétitivité

Les développeurs se consacrant uniquement au code de la fonction attendue, ils sont en mesure de délivrer plus de valeur plus rapidement aux clients.

Les limites du serverless

Vendor locking

Chaque cloud provider a son propre framework. A ce jour aucune spécification n’est sortie afin d’adopter un langage commun entre les fournisseurs.


Latence

Comme vos fonctions sont exécutées dans un conteneur qui est créé à la demande pour répondre à un événement, une certaine latence lui est associée. C’est ce qu’on appelle le démarrage à froid ou Cold Start.


Supervision

A ce jour les seuls solutions possibles pour effectuer le monitoring et le debeug de vos fonctions sont celles fournies par les cloud providers et elles ne sont pas encore au niveau attendu.

Les cas d’usage

Actuellement, le serverless peut être utilisé lorsque l’exécution du code est déclenchée par un événement métier et plus généralement chaque fois qu’on rencontre un fonctionnement event-driven. C’est le cas pour de nombreux domaines :

  • les applications IoT
  • les applications mobiles
  • l’authentification
  • le Machine Learning
  • l’exposition d’APIs
  • les sites internet
  • le traitement d’information (temps réel ou batch)

En revanche il est inadapté pour les cas suivants :

  • tâches lourdes et complexes
  • tâches nécessitant de maintenir une connexion active avec ses clients
  • si votre code est exécuté à intensité constante (explosion des coûts)

Néanmoins, ces contraintes s’appliquent parfois seulement à une partie d’une application.