Serverless, les prérequis et les contre-indications

  1. La technologie Serverless, la transparence de paiement
  2. La méthode PERT et la construction du réseau PERT
  3. CNSS RDC: historique et caractère de la sécurité sociale
  4. Etude des moyens de la CNSS en RDC
  5. Serverless: définition et conception de l’architecture
  6. Serverless, les prérequis et les contre-indications
  7. Qu’est-ce qui ne fonctionne pas en Serverless ?
  8. Modélisation du système d’information Serverless
  9. Le serverless: langages de script et de programmation

Le Serverless, les prérequis et les contre-indications

1.4 Les prérequis pour introduire le serverless dans notre organisation

1.4.1 Un découpage en fonctions

Il est conseillé de repenser l’application – au moins partiellement – pour la découper en fonctions qui détiennent chacune une responsabilité précise.

Ce découpage est comparable au passage d’une architecture monolithique à une architecture en microservices.

Par conséquent, si notre produit est déjà basé sur une architecture microservices, passer au moins partiellement au serverless sera bien plus facile.

1.4.2 La compatibilité du code

Étant donné que la fonction sera hébergée et déployée sur un Cloud Provider serverless, elle doit respecter les règles mises en place par le Cloud Provider choisi.

Les deux règles principales sont :

– les langages : AWS Lambda n’accepte par exemple nativement que des fonctions écrites en C#, Java, Node.js, Go, Ruby ou Python. Des solutions existent néanmoins afin de pouvoir faire fonctionner n’importe quel autre langage, comme PHP par exemple, sur Lambda.

Pour notre cas nous avons fait tourner nos fonctions sur Lambda en utilisant le langage PHP déployer à l’aide d’un plugin du WordPress

– le respect du temps limite d’exécution de la fonction (15 minutes sur AWS Lambda mais ce temps limite est abaissé à 30 secondes si l’événement qui invoke la fonction est une requête HTTP)

Screenshot de la console AWS
Screenshot de la console AWS

13 www.serverless.com, consulté le 14 Avril 2020 à 16h18

1.5 Contre-indications de serverless

Le serverless est plein de promesses mais il n’est pas adapté pour tous les cas d’usages.

Du fait de la limitation du temps d’exécution, il est inadapté aux tâches lourdes et complexes comme du traitement vidéo, ou aux tâches qui nécessitent de maintenir une connexion active avec ses clients.

D’autre part, si notre code est exécuté à intensité constante, le serverless coûtera plus cher à notre organisation qu’un hébergement classique14.

Néanmoins, ces contraintes s’appliquent peut-être uniquement à une partie de notre application.

Dans le cas où d’autres parties, comme l’authentification par exemple, ne nécessitent pas de ressources allouées en permanence, il est possible de les externaliser dans une fonction serverless.

1.6 Quelques exemples de cas recourant au serverless15

Afin d’illustrer le fonctionnement et l’approche Serverless, voici des exemples de Use Cases.

1. Application Web

Prenons l’exemple d’un site e-commerce. Il s’agit d’une application Web 3- tiers avec la logique côté serveur.

exemple d'un site e-commerce
Figure 6: exemple d’un site e-commerce

Avec cette architecture, le client ne contient pratiquement aucune logique comparée au serveur (authentification, navigation de page, recherche, transactions).

Étude comparative des sites e-commerce français et chinois

Avec une architecture Serverless, cela pourrait finir par ressembler davantage à ceci :

Architecture Serverless
Figure 7: Architecture Serverless

Il s’agit d’un exemple de transposition de l’architecture précédente en Serverless. Il y a un certain nombre de changements importants qui se sont produits ici.

14 www.serverless.com, consulté le 14 Avril 2020 à 17h00

15 www.serverless.com, consulté le 14 Avril 2020 à 17h22

Notons que ce n’est pas une recommandation d’une migration architecturale, on utilise simplement comme un outil pour exposer certains concepts sans serveur.

– Plus besoin d’héberger nos fichiers Web sur un serveur, un simple

bucket et un outil de gestion du cache peuvent suffir.

– Nous avons supprimé la logique d’authentification et l’avons remplacée par un service tiers BaaS (Auth0, AWS Cognito, …).

– En utilisant un autre exemple de BaaS, nous avons permis à un client d’accéder directement aux données (listes de produits), hébergées par un tiers (AWS Dynamo, Firebase).

Nous pouvons aussi établi des règles de sécurité strictes liées aux profils utilisateurs et ainsi gérer les restrictions d’accès aux données.

– Les deux points précédents impliquent un changement important des rôles des tiers : la logique est passée du serveur au client (exemple : suivi d’une session utilisateur, UX, lecture de données et affichage dans une vue utilisable.

– Certaines fonctionnalités sont à garder côté serveur, par exemple, si elles impliquent des calculs intensifs ou nécessitent l’accès à des quantités importantes de données (recherche de produits).

Pour cette fonctionnalité, au lieu d’avoir un serveur toujours en cours d’exécution, nous pouvons implémenter une fonction FaaS qui répond aux requêtes HTTP via une API Gateway.

– Finalement, nous pouvons remplacer la fonctionnalité “Achat” par une autre fonction FaaS, en choisissant de la garder sur le côté serveur pour des raisons de sécurité.

Avec ce changement d’architectures, nous avons un nouveau panel d’outils à notre disposition comme l’API Gateway.

Pour faire simple, cet outil permet de définir des endpoints sécurisés accessible de l’extérieur et de rediriger l’appel vers un service de traitement (génération d’un événement, lancement d’une fonction) qui une fois fini pourra retourner des données selon les besoins.

2. Application basée sur les événements (Event-driven)

Un autre Use Case d’architecture Serverless est l’analyse et le traitement de données asynchrones.

Prenons un cas que nous connaissons tous, le tracking d’activités des utilisateurs d’une application. Le besoin est d’arriver à connaître les activités précises d’un utilisateur sans impacter les performances de l’application.

Nous pourrons ainsi déporter la logique permettant l’envoi/réception d’un événement de navigation et son enregistrement au sein d’une base de données de type BaaS.

Architecture Serverless basée sur les événements
Figure 8: Architecture Serverless basée sur les événements

Voici l’exemple d’une architecture d’application Web basique possédant une fonction de tracking Serverless (zone rouge)

Ce service est assuré à l’aide d’une API Gateway, fonction permettant la déclaration d’endpoint et son mapping vers un service de traitement, ici une fonction de type FaaS.

Elle-même est en charge de l’enregistrement des données auprès d’une base de données de type BaaS.

3. L’IoT et son envoi d’informations effectué par des milliers de capteurs

Un autre exemple très en vogue de nos jours concerne l’IoT et son envoi d’informations effectué par des milliers de capteurs.

Nous n’avons aucun besoin d’une communication synchrone entre la partie serveur et les capteurs, en revanche l’objectif est la récupération des informations, son stockage et son analyse.

Un exemple de cet Use Case est la maintenance prédictive.

Après la récupération des données brutes issues des capteurs, des algorithmes vont les analyser et pouvoir conjecturer et “prédire” une panne ou un besoin de maintenance d’un équipement.

Architecture Serverless de L'IoT
Figure 9: Architecture Serverless de L’IoT

Dans cette architecture nous utilisons des systèmes BaaS pour la gestion des flux de données (exemple : AWS Kinesis ou Google Cloud Pub/Sub) puis des systèmes FaaS pour le prétraitement, le pré-calcul ainsi que l’enregistrement de celles-ci dans une base de données fournis par un système BaaS.

Cliquez sur suivant article pour lire la suivante partie de ce mémoire:

Abonnez-vous!
Inscrivez-vous gratuitement à la Newsletter et accédez à des milliers des mémoires de fin d’études !
Publier son mémoire!
WikiMemoires - Publier son mémoire de fin d’études !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *