VT2016 Serverless Architectures
Présentation
- Sujet : Serverless Architectures
- Auteur : Régis Ramel
- Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU
Mots clés
Cloud computing, Platform as a Service, Function as a Service, AWS Lambda
Résumé
Les architectures sans serveurs sont un nouveau types d'architectures d'applications réparties basées sur le cloud qui permettent d'abstraire l'infrastructure des serveurs sur lesquelles tourne l'application. Le principe est d'utiliser un fournisseur de service qui va gérer le déploiement et la maintenance du matériel à la place des développeurs. L'infrastructure est mise à la disposition des clients qui n'ont plus qu'à gérer le développement et la maintenance de leur application.
Abstract
Serverless architectures are new types of distributed applications architectures based on cloud computing which allow to abstract network infrastructure, including servers which run the application. The concept involve a service provider who manage the deployment and the maintenance of the hardware for developpers. The infrastructure is made available to the clients who then only have to manage de development and the maintenance of their application.
Synthèse
Introduction
Une très grande partie des applications et services développés aujourd’hui ont besoin d’une infrastructure pour fonctionner. Il peut s’agir d’un parc de serveurs pour héberger les données des clients, ainsi que les bases de données nécessaires au fonctionnement de l’application, ou alors des machines virtuelles pour effectuer les calculs de manière centralisée. La gestion de l’infrastructure est cruciale pour les développeurs : Quelle capacité de stockage doit-on avoir ? Quelle charge les serveurs doivent-ils supporter ? Comment peut-on renforcer la stabilité et la disponibilité de l’infrastructure.
Depuis quelques années, le développement du cloud computing a changé la façon de créer et de gérer des applications réparties, et a permis de répondre à tous ces problèmes grâce à la technologie des Infrastructures sans serveurs (Serverless Infrastructures).
Historique
Les années 2000 ont vus l’apparition des Logiciels en tant que Services (Saas), basés sur le cloud. Il s’agit d’utiliser des logiciels installés sur des serveurs distants au lieu du matériel de l’utilisateur. Cela permet à une entreprise, par exemple, de simplifier ses coûts de fonctionnement informatique en un simple abonnement à un ensemble de services. Pour aller plus loin dans l’abstraction de l’infrastructure sur laquelle tourne une application, L’entreprise Fotango a développé la Plateforme Zimki, qui permettait aux développeurs de simplifier le déploiement de leurs applications en automatisant la gestion et la configuration des parcs de serveurs, ainsi que des problèmes de sécurité et de montée en charge. C’est l’invention de la Plate-forme en tant que service. En 2008, Google lance App Engine, une PaaS qui permet de faire tourner des codes Python, Java, Go et PHP sur des serveurs Google. En 2014, Amazon ajoute AWS Lambda aux Amazon Web Services. Lambda permet de lancer des scripts Python Java ou Node.js, ou encore des exécutables Linux, en fonction d’évènements. C’est le principe de la Fonction en tant que Service (FaaS).
Principe de fonctionnement
Les architectures sans serveurs ont pour but de simplifier la gestion d’application réparties en laissant un fournisseur de services s’occuper de l’infrastructure plutôt que de gérer un parc de serveurs et de machines virtuelles prédéfinis. Il existe deux principes d’architectures sans serveur basés sur le cloud computing : la Plate-forme en tant que Service, et la Fonction en tant que Service
Platform as a Service (Paas)
La Plate-forme en tant que Service fourni à l’utilisateur un environnement pour faire tourner une application, c’est à dire un serveur qui va exécuter le code. Pour le client, cela présente l’avantage de lui éviter de gérer le matériel, c’est-à-dire l’emplacement et le nombre de serveurs ainsi que toutes les problématiques d’une infrastructure d’une application répartie (redondance, sécurité, gestion des pannes, remplacement des serveurs).
Fournisseurs : Google App Engine, AWS Elastic Beanstalk, Microsoft Azure, IBM Bluemix
Function as a Service
La Fonction en tant que Service reprend le principe de l’abstraction de l’infrastructure réseau de la Plate-forme en tant que Service, mais a un modèle de fonctionnement différent. Il s’agit d’un système plus adapté à des applications qui vont lancer des fonctions en réponses à des évènements. Lorsque l’application appelle une fonction, la FaaS alloue les ressources nécessaires pour exécuter le code correspondant sur les serveurs du fournisseur. L’allocation de serveurs dans le cloud s’adapte à la quantité de données à traiter ou de la charge de l’application. Ainsi, en fonction de l’utilisation de l’application, l’architecture s’adapte dynamiquement. Ce principe est notamment très efficace pour la programmation orientée composant, ou un composant ne va être utilisé que lorsqu’il est sollicité pour exécuter une requête.
Fournisseurs : Google Cloud Fonctions, AWS Lambda, Microsoft Azure Functions, IBM OpenWhisk
Démonstration d'AWS Lambda
La démonstration consiste à enregistrer une fonction python dans AWS Lambda, et à la tester pour vérifier le feedback obtenu et les possibilités de monitoring.
La fonction consiste à lire dans une structure de données de type json, la valeur correspondant à la première clé.
Voici le code python entré dans AWS Lambda :
from __future__ import print_function
import json
print('Loading function')
def lambda_handler(event, context):
#print("Received event: " + json.dumps(event, indent=2))
print("value1 = " + event['key1'])
print("value2 = " + event['key2'])
print("value3 = " + event['key3'])
return event['key1'] # Echo back the first key value
#raise Exception('Something went wrong')
De cette façon, lorsque l'on entre dans la configuration du test
{
"key1": "value1",
"key2": "value2",
"key3": "value3"
}
On obtient en retour :
"value1"
On peut également afficher des courbes qui renseignent sur les statistiques d'invocations de la méthode (Nombre d'appels, durées des appels, ...) :
