VT2017 Serverless Architectures

From air
Jump to navigation Jump to search

Présentation

  • Sujet : Serverless Architectures
  • Auteur : Antoine Boisadam
  • Enseignants : Didier Donsez, Georges-Pierre Bonneau
  • Date : 15/09/2017
  • Démo

OpenWhisk.jpeg

Résumé

Une architecture qualifiée de serveless est une architecture où l'utilisateur n'a plus à gérer la moindre infrastructure (machine, VM, ...). Le serveur existe toujours bel et bien, mais il est "caché" aux développeurs. Un des gros avantages de ce type d'architecture est que la mise à l'échelle est automatiquement gérée. Les développeurs créent des fonctions et les exécutent à la suite d'un ou plusieurs événements. OpenWhisk est une plateforme open source, poussée par Apache, qui permet de mettre en place une architecture serverless. OpenWhisk permet donc d'exécuter des fonctions JavaScript (Node.js) ou Swift, en réponse à des événements et à n'importe quelle échelle. IBM, entre autres, et son service IBM Function héberge un serveur OpenWhisk et offre ce service.

  • Mots-clés : calcul, infrastructure, fonctions, évenements, cloud, mise à l'echelle, disponibilité

Abstract

A serverless architecture is an architecture where developers don't have to care about the infrastructure (machine or VM), it's managed by a 3rd party. One of the biggest benefits of this kind of architecture is the scalability. Developers can focus on code and can create functions which will be triggered by an event. Apache OpenWhisk is a serverless, open source cloud platform that allows you to execute code in response to events at any scale. OpenWhisk handles the infrastructure and servers so you can focus on building amazing things (website definition). OpenWhisk is able to execute Javascript and Swift code. IBM, with IBM Function, provide an OpenWhisk service.

  • Keywords : computing, infrastructure, functions, server, events, cloud, scalability, availability

Synthèse

La mise en place de serveurs, qu'ils soient hébergés dans l'entreprise ou chez un fournisseur en ligne, leurs configurations et le déploiement d'applications sur ceux-ci peut s'avérer très coûteux (en terme d'homme/temps et aussi matériel). C'est pour ces raisons que ces dernières années, les architectures dîtes serverless se sont démocratisées.

Le principe

Une architecture serverless est une architecture où l'utilisateur n'a plus à gérer la moindre architecture. Il se concentre exclusivement sur la conception. Serverless ne signifie pas sans serveur mais que le serveur est invisible pour l'utilisateur. Il y a donc un impact sur les coûts.

TBC..

Avantages et inconvénients

La technologie parfaite n'existe pas encore, c'est pourquoi j'expose ici les avantages et inconvénient d'une telle architecture.

Avantages

  • Coûts réduits : En effet, pas de serveur physique = pas de frais d'achat et maintenance de matériel, ni de dépense électrique pour faire tourner et refroidir un (ou plusieurs) serveur(s). Un serveur hébergé dans l'entreprise, qui rend un site web, doit disponible 100% du temps (ou du moins, le plus possible).
    Lors de l'utilisation d'une architecture serveless, les coûts sont également réduits car les fournisseurs facturent à l’appel de fonction (et pas à la minute de uptime comme lorsqu'on paie un serveur traditionnel) : on payera donc en fonction du nombre d'utilisateur sur notre application (au lieu d'un coût "fixe").
  • Mise à l’échelle : Les cloud provider ont mis en place de la parrallèlisation d'action. Comme il y a un conteneur par action, il n'y a plus de surchage d'un conteneur puisqu'on peux en créer X conteneurs pour X actions.
  • Informatique plus « vert » : Le serveur ne tourne plus 24h/24 et les fournisseurs peuvent faire tourner plusieurs actions sur un même serveur (physique). Il faut s'avoir, qu'en moyenne 5 à 15% des data-centers des entreprises sont utilisés, il y a donc une possibilité d'amélioration avec cette architecture.
  • Sécurité : La sécurité étant totalement géré par le fournisseur, la majorité des barrières aux attaques informatiques (proxy, anti-DDOS, ...) n'étant plus à mettre en place par l'équipe technique de l'entreprise.

Inconvénients

  • Dépendance au cloud provider : Effectivement, si le fournisseur ferme ou est ne fonctionne plus un temps, c'est vers vous que les utiliseurs se retourneront car votre application finale ne "fonctionne pas"
  • Durée d’exécution : On a là deux problématique, quid du timeout et quid de la latence au démarrage ? C'est à dire, si la fonction met plus de 5 minutes à rendre un résultat, que ce passe-t-t-il ? Pour la latence au démarrage, comme il faut créer un conteneur à chaque exécution, les fournisseurs ne laissent pas pour l'instant un choix infini de langage exécutable. On retrouve souvent Javascript (Avec Node.JS) pour ces performances.
  • Non applicable à tous les projets : Pas de solution miracle, même si on peux appliquer une architecture serveless à plus de 90% des scénarios.
  • Sécurité : C'est aussi un avantage, mais il faut penser que si le fournisseur subit un hack ou autre, c'est aussi les données de l'entreprise qui sont en danger. Attention aux données externalisées !


OpenWhisk

OpenWhisk est un projet aujourd'hui open-source et propulsé par Apache (https://openwhisk.incubator.apache.org/). Ce projet permet de mettre en place un serveur qui fonctionne en temps que fonction (ou action) qui répond à un événement.

Openwhisk-principe.png

IBM propose un service IBM Function qui propose d'utiliser cette architecture : https://console.bluemix.net/openwhisk

Webographie