Applications Cloud sans serveur, la fin des coûts d’infrastructure ?

Temps de lecture : 3 minutes

L’ère des applications coûteuses pour l’entreprise est-elle révolue ? Il est aujourd’hui établi que le cloud a considérablement réduit les coûts d’infrastructure IT, tout en offrant une souplesse de gestion inédite, mais les services les plus récents d’AWS ouvrent la porte à une nouvelle perspective, celle des applications sans serveur. Ce qui signifie des applications au coût d’infrastructure proche de zéro…

Les applications sans serveur sont déjà une réalité, et pour l’illustrer nous avons choisi l’exemple d’un de nos clients souhaitant développer un service de dépôt de fichiers. Le besoin initial exprimé par le client était de permettre à des utilisateurs issus de départements différents de pouvoir déposer des fichiers comptables, qui seraient ensuite centralisés avant d’être envoyés à un service externe. Ce service traite les fichiers en effectuant des calculs et des simulations, avant de remettre des résultats.

Dans le cadre de ce projet, le client souhaitait pouvoir uploader les fichier sur S3, le service de stockage d’objets dans le Cloud proposé par AWS. Plutôt que de développer spécifiquement une application, D2SI a conseillé de s’appuyer sur une application AngularJS utilisant les nouveaux services AWS : Lambda et API Gateway. Concrètement, l’utilisateur uploade ses fichiers dans une interface de type Dropbox, en utilisant simplement un navigateur web. Le fichier choisi est uploadé, ensuite un ensemble de règles de gestion d’autorisation, de contrôles sur les les fichiers, sont déclenchés par les Lambdas AWS. Pour découvrir Lambda plus en détail, voir notre article sur les nouveaux services AWS  ici.

Ici les lambdas AWS sont principalement utilisées pour la gestion des permissions (validation de l’utilisateur, création du token), et pour l’upload du fichier, sa validation et sa copie. La complexité vient surtout de la gestion des permissions, de faire en sorte que l’utilisateur soit authentifié, validé, puis de transformer l’autorisation Google (token OAuth) en autorisation Amazon (token SAML, Security Assertion Markup Language). Par exemple, le token ne contient pas d’information sur les groupes auquel appartient l’utilisateur : c’est la lambda qui est chargée de récupérer cette information. L’utilisateur a ensuite la possibilité de choisir son groupe s’il appartient à plusieurs groupes.

L’intérêt principal de cette solution est de réduire considérablement les coûts d’infrastructure grâce aux nouveaux services AWS Lambda et Serverless. Ce type d’architecture est appelé à se développer sur le marché : Google et Azure ont récemment annoncé des services équivalents (Google Cloud Functions). Dans le cas de Lambda, le facturation se fait à l’exécution, en fonction de la taille du container (mémoire/CPU), et à la durée, comptabilisée en centaines de millisecondes. Sachant que le premier million d’exécutions est gratuit, et que le million supplémentaire est facturé 0,2$. Ici, avec quelques centaines d’exécutions par mois, le coût est donc nul. Reste le coût de stockage sur S3, négligeable puisqu’il s’agit de fichiers textes. Pour obtenir un service équivalent avec des VM, il faudrait compter au moins 50$/mois d’architecture pour assurer la résilience du service; cependant on n’aurait pas pu bénéficier des fonctions de déclenchement proposées par les lambdas.

Commentaires :

A lire également sur le sujet :