X
 
Le Serverless... Prêt pour la production ?
Thèmes: Cloud, Dossier, Infra

Le Serverless... Prêt pour la production ?

Considéré comme l’architecture informatique du futur, le « Serverless » ou « calcul sans serveur » suscite beaucoup d’interrogation. Si les premiers services cloud tiennent leurs promesses, la technologie a aussi des contraintes. Et toutes les applications ne n’y prêtent pas… Pour l’instant.

Dans un discours qui a constitué l’acte fondateur du mouvement Serverless, Werner Vogel, l’emblématique directeur technique d’Amazon Web Services, déclarait lors de l’AWS Summit de 2015 : « No Server is easier to manage than no server »(1). Derrière cette citation plutôt énigmatique, le géant américain du Cloud dévoilait son offre Serverless, AWS Lambda. Si le principe de base du Serverless avait déjà été défini près d’une dizaine d’années plus tôt, avec cette offre, Amazon Web Services était le premier gros acteur du Cloud à lancer une offre commerciale de ce type à grande échelle.

Du FaaS et du BaaS

Il est maintenant admis que le Serverless sera l’architecture informatique qui succédera à la conteneurisation. Le principe de base du serverless est d’une simplicité biblique : le développeur charge sa fonction à exécuter sur le service cloud, à charge à l’opérateur d’assurer son exécution sans se soucier du nombre d’appels simultanés. « Les équipes DevOps peuvent se concentrer sur la partie qui a le plus de valeur ajoutée pour l’utilisateur final, c’est-à-dire le code », résume Laurent Grangeau, Cloud Solution Architect chez Sogeti. « Toute la plomberie d’hébergement, de scalabilité et de résilience est gérée par le Cloud provider, et non plus par une équipe dédiée dans des datacenters en propre. » Ce volet exécution de code dans le Cloud est baptisée FaaS pour « Function as a Service », mais le Serverless inclut aussi le volet BaaS pour Backend as a Service. Il s’agit d’une série de services qui vont pouvoir être consommés par les applications Serverless. On classe les bases de données parmi ces BaaS, mais aussi les services de gestion d’identité, des buses de messages, des traitements de type ETL ou encore des capacités de Webhook pour déclencher des fonctions selon les événements HTTP, etc.

Outre une simplification d’architecture, le Serverless présente un argument clé, son modèle tarifaire : « L’autre atout du Serverless, c’est la consommation en pay-percall », explique Laurent Grangeau. « Lorsqu’un environnement est provisionné et qu’aucun appel n’est fait sur cet environnement, il n’y a aucun cout supplémentaire, contrairement à une approche IaaS, ou l’environnement est facturé en fonction de son uptime. De ce fait, les coûts peuvent être drastiquement réduits, passant de plusieurs centaines d’euros par mois, à quelques centimes dans certains cas. » Ce nouveau modèle économique est encore plus précis que la location d’une instance de serveur à l’heure ou même à la minute et, comme le souligne Virginie Mathivet de TeamWork, une facturation par incréments de 100 millisecondes est particulièrement adaptée à l’IoT où il faut lancer un traitement à l’arrivée épisodique d’événements générés par les objets connectés. Toutefois, dès que ces événements surviennent en continu, les courbes de coûts peuvent se croiser entre la location d’une instance IaaS en continu et le Serverless.

 

Sites internet hébergés par Amazon S3. Une architecture de site web type sur la plateforme Serverless Amazon Web Services, avec les appels qui transitent par l’API Gateway en direction des fonctions exécutées par le service Lambda.

Le Serverless bien adapté aux spécificités de l’IoT

L’IoT, où l’on doit lancer une fonction au moment de l’arrivée d’une donnée, ou encore le Big Data, se prête bien à ce nouveau mode de consommation de puissance informatique dans le Cloud, il est aussi possible de créer des applications Web sur une architecture Serverless, placer une fonction FaaS derrière une API, lancer une action de manière planifiée via des commandes cron, réalisé un traitement à l’appel d’une url dans une page, lancer une fonction lorsqu’on copie un fichier dans le Cloud ou même lorsqu’on sauve un fichier Excel sur Onedrive. IBM a même fait la démonstration d’une chaîne de traitement d’analyse d’images vidéo d’un drone en temps réel. Dans cette application baptisée Skylink, une fonction serverless étant chargée d’envoyer les images à analyser à IBM Watson puis de récupérer les résultats, des tags décrivant les objets identifiés dans l’image afin de les afficher en marge du flux vidéo.

Si les applications temps réel ou interagissant avec les utilisateurs sont théoriquement possibles en s’appuyant sur une infrastructure Serverless, le support des langages de programmation par les opérateurs de services FaaS est un élément important dans le choix d’une plate-forme. Ce choix est important notamment en termes de performances. En effet, Le Serverless présente la caractéristique d’avoir un temps de latence important lors du premier appel d’une fonction, c’est le phénomène du « Cold Start ». C’est globalement le temps mis par l’infrastructure de l’opérateur cloud de monter en mémoire le conteneur qui contient la fonction appelée, sachant que le conteneur va être effacé au bout de quelques minutes d’inactivité. Pour des traitements IoT ou des batchs destinés à alimenter un Data Lake, ce délai d’exécution n’est pas nécessairement un handicap, en revanche, s’il s’agit de supporter des API RESTful qui doivent être très réactives ou des applications web destinées à des utilisateurs « humains », ce phénomène peut être très handicapant. Steve Houel, architecte solution chez Ippon Technologies souligne que « Sur un projet que nous menons actuellement pour un gros industriel, nous n’avons aucun soucis au niveau architecture. Mais si un utilisateur fait un appel à une fonction très peu utilisée, il peut avoir un délai de 15 à 20 secondes avant d’avoir une réponse. » L’expert souligne que le choix du langage influe très directement sur ce délai d’exécution. « AWS offre cinq langages pour son service Lambda et chacun de ces langages à un temps de Cold Start. Mettre en œuvre le Java et sa JVM implique un temps de chargement qui peut atteindre la minute ! » Un tel temps d’attente peut paraître incompréhensible pour les utilisateurs d’une nouvelle application, surtout si on leur explique que celle-ci met en œuvre l’architecture la plus novatrice du moment… Pour masquer ce phénomène, les développeurs utilisent des subterfuges et font des appels réguliers à chaque fonction « à blanc » via un fichier « cron » afin que celles-ci restent en permanence en mémoire et ainsi épargner les utilisateurs de « Cold Start » pendant leur journée de travail.

Du Serverless en on-premise, c’est possible !

L’approche Serverless semble totalement liée à la notion de Cloud public et pourtant des solutions permettent de déployer une architecture Serverless sur des serveurs on-premise et donc sur un Cloud privé. Outre Fn Project et Apache OpenWhisk, les solutions mises en œuvre par Oracle et IBM, il existe plusieurs frameworks alternatifs. Parmi eux, Kubeless, fission ou OpenFaaS basés sur Kubernetes, ou encore Dispatch, un framework Serverless Open Source qui a été annoncé lors de VMworld 2017. Édité sous licence Apache 2.0, cette solution pourrait intéresser les entreprises dont le Cloud interne est motorisé par les solutions de virtualisation VMware. Enfin, pour les entreprises adeptes des technologies Microsoft, l’éditeur propose un runtime d’Azure Functions pour Windows 10, mais ont aussi été mis à la roadmap une version Linux et Mac de la plateforme Serverless de Microsoft. Ces versions sont actuellement au stade de la préversion.

 

Pour l’heure, les experts estiment les plates-formes Serverless pas assez matures pour supporter de lourdes applications composées de plusieurs dizaines de fonctions. Néanmoins, les offres évoluent rapidement, notamment afin d’industrialiser les déploiements de grand nombre de fonctions et aller vers le Graal du NoOps, c’est-à-dire d’une architecture qui ne nécessite plus aucune opération de maintenance. Laurent Grangeau souligne que « L’un des plus gros inconvénients du Serverless aujourd’hui porte sur le test de telles architectures, que ce soit de manière unitaire, mais aussi de bout en bout. Cela oblige les développeurs à mettre l’accent encore plus sur des méthodes type TDD (Test Driven Development), découplant le code métier, de la plomberie propre à chaque Cloud provider, afin de pouvoir tester unitairement chaque fonction, ou la bouchonner. » L’expert estime que ces inconvénients vont peu à peu s’estomper grâce à une standardisation de l’architecture serverless, standardisation initiée par la publication du « Serverless Whitepaper 1.0 » par la Cloud Native Computing Foundation. Pour Adrien Blind, l’enjeu pour le futur va être de désenclaver le Serverless. « Les applications de demain ne se limiteront pas à seulement des fonctions Serverless mais seront des hybrides entre du FaaS, des microservices plus traditionnels, des composants exécutés sur du Iaas, etc. Il faudra être capable d’orchestrer le déploiement et administrer des éléments d’infrastructures de natures différentes et être capable de le faire dans des environnements de Continuous delivery et DevOps. » Être capable de gérer de telles applications hétéroclites va être un vrai enjeu pour les années qui viennent.


(1) Lire aussi à ce sujet la Rencontre, parue dans le n°165 de L’Informaticien (p. 20) avec Julien Lepine, patron européen des architectes d’Amazon Web Services.


 

« Avant tout, bien choisir son cas d’usage »
Steve Houel, architecte solution chez Ippon Technologies

« Le Serverless peut être mis à profit dans de très nombreux cas, notamment pour faire de l’analyse de données, des traitements de type Big Data, ou même pour porter des applications web. Dans chaque cas d’usage, le Serverless présente des atouts et des inconvénients. Si on prend une architecture type AWS, il est difficile de faire une application web en Serverless, notamment du fait de la latence liée au « cold start ». Même si une fonction est totalement scalable, cette latence au premier démarrage va potentiellement nuire à l’expérience utilisateur. » « La maturité de cet écosystème, même si AWS a trois ans d’avance sur ses concurrents, tous les outils open source sont encore assez peu matures et les use case rares pour traiter des use case professionnels. AWS a sorti un langage de templetisation d’infrastructure, le langage SAM (Serverless Application Model), c’est très prometteur, mais on si on veut déployer plus de 40 fonctions Lambda, ce qui reste relativement peu, on ne peut pas, il faut revenir à CloudFormation sur AWS. La technologie est véritablement très prometteuse et imbattable sur certains cas d’usage bien déterminés. »


 

« Avec le Serverless, je suis autonome dans  la mise en place de mes architectures »
Virginie Mathivet, ingénieur innovation. chargée de R & D chez TeamWork

« Je travaille sur des sujets en IA et en IoT, pour des clients ou dans la recherche, et dans ce cadre, j’ai besoin de mettre en place et de tester rapidement des algorithmes. Avec l’architecture Serverless, je n’ai pas à me soucier de mettre en place des serveurs, d’installer des outils ou d’avoir à solliciter les Ops. Je peux rester autonome, monter l’architecture dont j’ai besoin sur AWS en quelques clics, tout en profitant de l’intégration native des volets scalabilité, sécurité, etc. C’est un énorme gain de temps pour moi. Le Serverless me permet de travailler sans avoir à gérer le moindre serveur, ce n’est pas qu’une promesse. » « L’autre atout, c’est le prix car les ressources ne sont actives que lorsque l’on s’en sert, avec une facturation à l’usage (100 ms pour AWS Lambda par exemple. Lorsque, comme moi, on fait de l’IoT en Serverless, on paie au moment où l’on reçoit et traite le message, mais rien entre deux messages. Il y a cependant un inconvénient financier pour les applications fortement sollicitées (appels d’AWS Lambda en permanence), qui peuvent revenir plus chères qu’une instance EC2 seule. En revanche, les autres avantages sont eux toujours là : la scalabilité – notamment lorsqu’on travaille à très haute échelle et qu’il faut faire face à des pics de production très élevés –, la disponibilité, quelle que soit la charge ou encore la sécurité. »


 

« Le Serverless tend vers le NoOps »
Adrien Blind, évangéliste technologique dans une grande banque française, Docker Captain.

« Le Serverless – et plus précisément le FaaS – va plus loin que le PaaS, qui apportait déjà un niveau d’abstraction sur l’infrastructure. Le FaaS va plus loin en termes de granularité, on passe de l’échelle du microservice à celui de la fonction et, surtout, les développeurs n’ont plus à gérer la scalabilité et l’opérabilité de l’infrastructure. On tend vers le NoOps, même s’il reste encore l’aspect métrologie et supervision du code métier déployé sur le FaaS. » « Le modèle Serverless apporte des bénéfices réels, mais il apporte son lot de contraintes. Il faut faire entrer son code dans le paradigme des plates-formes FaaS. Celui-ci doit respecter un certain nombre de contraintes et les applications qui nécessitent beaucoup d’informations de contexte vont avoir du mal à se plier à ces contraintes. Le code Stateless s’accommode bien du FaaS, mais en règle générale, les applications doivent avoir été pensées pour être déployées dans ces environnements Serverless. »

 

Print
3799

x
Rechercher dans les dossiers

Actuellement à la Une...
Après Oodrive en janvier, c’est au tour de Outscale d’obtenir la précieuse qualification SecNumCloud, délivrée par l’Anssi. Outre la reconnaissance des engagements de la filiale de Dassault Systèmes en matière de sécurité, ce « visa de sécurité » est surtout un argument dont Outscale pourra se targuer auprès de ses clients.

Big Blue est réputée pour ses avancées technologiques développées dans ses laboratoires. IBM Research a encore frappé avec un nouvel algorithme capable de synthétiser les réseaux de neurones profonds.

Le Cloud pour les grandes entreprises de Dell Technologies se rénove pour apporter une meilleure gestion du stockage et une meilleure visibilité sur les coûts.

Compuware vient de rendre publique une étude réalisée pour son compte par Vanson Bourne auprès de 400 responsables informatiques dans le monde. Le principal résultat est que seulement 7 % des entreprises ont automatisé leurs tests d’applications sur mainframe.

Pour beaucoup d’applications, un faible temps de latence reste un critère essentiel. Aussi le Cloud Amazon va multiplier ses implantations de petits datacentres au plus près de ses clients.

Sous la contrainte de la norme DSP2, le secteur bancaire est contraint d’évoluer vers des opérations plus ouvertes vers l’extérieur en suivant un concept relativement nouveau, l’Open Banking. HSBC s’appuie sur la plate-forme de Mulesoft pour créer de nouveaux services et mieux servir ses 38 millions de clients.

Si financièrement le temps n’est pas au beau fixe pour l’équipementier, il tente de rassurer à l’occasion de son évènement londonien, et mise sur l’intelligence artificielle, avec Mist sur la partie WLAN, pour renouer avec la croissance.

C’est une première : un outil développé dans le cadre du « Data Transfer Project » va être mis à disposition du public pour transférer des fichiers personnels entre deux grandes plates-formes, directement, sans téléchargement intermédiaire. Une pratique qui devrait se généraliser rapidement.

GitHub a sorti une nouvelle version en bêta de son service Actions. Publié pour la première fois en 2018, il est voué à l’organisation de workflows en liaison avec des événements. Sa principale nouveauté est le support de l’intégration et du déploiement en continu (CI/CD). La version finalisée était attendue pour la mi-novembre 2019. Article paru dans L'Informaticien n°181.

L’emblématique constructeur de voitures de sport certifie ses véhicules à la revente avec la blockchain de Salesforce. Celle-ci avait déjà servi à certifier une Lamborghini Aventador S comme une œuvre d’art.

Toutes les News
LIVRES BLANCS
Les entreprises et les organismes publics se focalisent aujourd’hui sur la transformation numérique. En conséquence, les DevOps et l’agilité sont au premier plan des discussions autour des stratégies informatiques. Pour offrir ces deux avantages, les entreprises travaillent de plus en plus avec les fournisseurs de services de cloud public et développent désormais des clouds sur site à partir d’une infrastructure qui répond à trois exigences de base:
1. Agilité sans friction des ressources physiques
2. Systèmes de contrôle optimisant l'utilisation des ressources physiques et offrant un retour sur investissement maximal
3. Intégration des divers composants de l'infrastructure pour un provisionnement et une gestion des ressources automatisés.


Pour fonctionner, votre entreprise doit pouvoir compter sur une solution de sauvegarde efficace, essentielle dans un monde marqué par une croissance exponentielle des données. Vous devez à la fois accélérer vos sauvegardes et pouvoir y accéder plus rapidement pour satisfaire les exigences actuelles de continuité d’activité, disponibilité, protection des données et conformité réglementaire. Dans cette ère de croissance effrénée, les cibles sur bande hors site et autres approches traditionnelles sont simplement dépassées.


L’Intelligence Artificielle promet de révolutionner la perception de la cybersécurité au coeur des entreprises, mais pas uniquement. Ce changement de paradigme engage, en effet, une redéfinition complète des règles du jeu pour les DSI et les RSSI, ainsi que l’ensemble des acteurs de la sécurité.


Lorsque l'on déploie des postes de travail, ils ont généralement tous la même configuration matérielle et logicielle (avec certaines spécificités selon les services). Mais on ne peut pas toujours tout prévoir et il arrive par exemple que de nouveaux programmes doivent être installés ou n’aient pas été prévus. L’accumulation de logiciels « lourds » est susceptible de provoquer des lenteurs significatives sur un PC allant jusqu’à l’extinction nette de l’application. Ce livre blanc explique comment optimiser les performances au travers de 5 conseils rapides à mettre en place.


Ce guide est conçu pour aider les entreprises à évaluer les solutions de sécurité des terminaux. Il peut être utilisé par les membres de l'équipe de réponse aux incidents et des opérations de sécurité travaillant avec des outils de sécurité des points finaux sur une base quotidienne. Il peut également être utilisé par les responsables informatiques, les professionnels de la sécurité, les responsables de la conformité et d’autres personnes pour évaluer leurs performances. les capacités de l’entreprise en matière de cybersécurité, identifier les lacunes dans la sécurité des terminaux et sélectionner les bons produits pour combler ces lacunes.


Tous les Livres Blancs