Cloud
Atouts et limites du Serverless Computing…
Par Laurent Delattre, publié le 10 août 2018
BaaS, FaaS, DBaaS, CaaS… Le serverless computing présente différents visages, mais des bénéfices communs qui séduisent de plus en plus les entreprises… Des atouts qui s’accompagnent aussi de limites à ne pas sous-estimer…
Technologie prometteuse, le serverless computing se développe très rapidement en entreprises. Dans ce concept, le fournisseur cloud est intégralement responsable du lancement et de l’exécution du code de vos applications, la plateforme s’assurant que les ressources nécessaires à leur fonctionnement optimal soient bien disponibles. Toutes les études le montrent, les technologies « sans serveur » connaissent aujourd’hui la plus forte croissance dans l’univers très varié des services cloud. Derrière ce terme se cachent plusieurs réalités que nous avons présentées dans une première partie : les différents visages du serverless…
Nous allons ici nous attacher à revenir sur les avantages, inconvénients et pièges éventuels de ces approches « serverless ».
Bénéfices du serverless
Partageant une philosophie commune, les différentes formes de serverless prodiguent également les mêmes bénéfices. Ces derniers sont principalement :
* Rapidité de développement
L’intérêt premier du Serverless est de raccourcir le temps nécessaire entre l’idée du projet et sa mise en production. Les développeurs n’ont plus à se soucier des problématiques d’infrastructure physique, de ressources et de systèmes d’exploitation. Ils peuvent entièrement focaliser leur attention sur la qualité du code et les fonctionnalités sans perdre de temps sur la plomberie logicielle nécessaire à la mise en œuvre.
* Montée en charge
Développeurs et équipes IT n’ont plus à se soucier des complexes problématiques de montée en charge. Pas de design, de paramétrages avancés et d’interminables phases de tuning pour s’assurer des capacités de mise à l’échelle de l’application. C’est le rôle du fournisseur cloud (et de sa plateforme serverless) de fournir les ressources nécessaires en fonction des besoins de l’application et ceci d’une façon totalement élastique.
* Fiabilité des exécutions
De par leur conception, les plateformes serverless sont généralement extrêmement résilientes et fiables. Les développeurs ayant également moins de lignes de codes à écrire, ils peuvent davantage focaliser leur attention sur la qualité des fonctionnalités qu’ils implémentent. Il en résulte des exécutions généralement plus fiables d’autant qu’elles s’appuient sur des ressources très élastiques.
* Efficacité économique
Avec le serverless, il n’y a pas de coûts liés à l’acquisition et l’installation de matériels, pas de coûts de systèmes d’exploitation et de licences attachées, pas de coûts de maintenance, pas de coûts de mise à jour des BIOS et des OS. Des avantages propres au cloud. Mais avec le serverless, l’entreprise fait également l’économie des ressources inutilisées comme toutes ces VMs trop souvent laissées allumées et pourtant totalement abandonnées. Le serverless s’appuie sur un modèle « pay-as-you-go » où l’entreprise ne paye que pour les ressources (mémoire, stockage et CPU) utilisées durant l’exécution même des codes. C’est particulièrement vrai pour le FaaS (Function as a Service) où vos codes ne sont exécutés que lors du déclenchement des évènements pour lesquels ils sont destinés à réagir : vous ne payez donc qu’au déclenchement de l’évènement durant le temps nécessaire à la réalisation de la fonctionnalité et pas au-delà.
Limites du serverless
Tout est toujours question d’équilibre. Ces bénéfices majeurs s’accompagnent nécessairement de limites et contraintes qu’il ne faut ni ignorer ni négliger…
* Attention aux latences
Les plateformes serverless sont pensées de façon optimale pour la montée en charge. La conséquence directe de cette conception, c’est que si une base de données (dans le cas du Database as a Service) ou une fonction (dans le cas du Function as a Service) n’est que très rarement appelée, elle affrontera un temps de démarrage plus long surtout comparé à des ressources équivalentes exécutées sur un serveur dédié. L’infrastructure serverless cherche en effet à optimiser l’usage de ses ressources sous-jacentes et donc libère tout ce qui n’est pas fréquemment utilisé entraînant un temps de réveil plus long (puisqu’il faut remplir les caches et recharger les frameworks d’exécution).
* Une liberté bornée
Tout particulièrement dans le cadre du FaaS, il existe souvent des contraintes propres à chaque plateforme qu’il faut connaître et intégrer. Typiquement, vos fonctions sont souvent limitées en taille de code et surtout en durée d’exécution.
Dès lors, il est important de ne pas perdre de vue que même si ces plateformes ont une excellente montée en charge, elles ne dédouanent pas les développeurs de délivrer du code de qualité.
* Un monitoring et un debugging plus délicat
La perte de contrôle liée au concept même du serverless rend plus complexe le diagnostic et la surveillance des applications notamment en matière de performance d’exécution et d’utilisation des ressources. Or, le système « pay as you go » impose d’avoir une bonne vision sur les temps d’exécution et les ressources consommées puisque ces éléments vous seront facturés.
Toutefois, cet aspect essentiel s’améliore peu à peu avec d’une part l’amélioration des outils de surveillance intégrés aux plateformes et surtout l’apparition d’outils tiers spécialisés dans le suivi des ressources cloud et de leurs coûts associés à l’instar de Dashbird, CloudWatch, Thundra, IOPipe, Stackerry ou OpenTracing.
* Une sécurité plus complexe
L’introduction du serverless dans vos politiques de sécurité vient ajouter encore plus d’hétérogénéité et donc de complexité. Le serverless tend aussi à augmenter votre surface d’attaque en multipliant les points d’accès et les technologies. En outre, ces technologies sont encore relativement immatures et mal maîtrisées par les responsables de la sécurité et par les développeurs. Bref, la sécurité de vos ressources Serverless ne doit pas être négligée et réclame une attention particulière même si les plateformes et les infrastructures sont, elles, bien protégées et défendues par l’opérateur cloud.
Des pièges à éviter
Le serverless a des atouts clés, mais le manque de compétences et d’outils propres à tout nouvel écosystème impose d’être conscient de certains risques et pièges, mais aussi de se méfier de certains à priori…
* Le déploiement reste une préoccupation
Sur le papier, le serverless simplifie à l’extrême toutes les phases de déploiement. C’est vrai à l’échelle unitaire. Mais lorsque l’on déploie des fonctions interdépendantes ou des conteneurs interdépendants, il faut mettre en place des procédures pour par exemple arrêter préalablement les services générateurs d’évènements et déployer simultanément tous les conteneurs ou fonctions mis à jour. Voilà qui n’a rien de nouveau, mais qui pose des problèmes d’organisation, de rollback en cas de soucis et de disponibilité des services que le serverless ne résout pas tout seul.
* Une responsabilité partagée
Comme pour le SaaS (Software as a Service), les multiples formes de serverless engendrent des responsabilités partagées entre le fournisseur de services (responsable de l’infrastructure matérielle et du bon fonctionnement de son service) et l’entreprise utilisatrice (responsable des données confiées au service et du respect des conditions d’exploitation du service). Ce qui a forcément un impact sur l’élaboration des contrats et le respect des SLA.
* Attention à la dépendance
Le serverless consiste à s’appuyer très intégralement sur un service fourni par un tiers ce qui nécessairement accroit la dépendance de vos développements à ce fournisseur. Qu’il s’agisse de BaaS (Backend as a Service), de FaaS, de DBaaS, ou dans une moindre mesure de CaaS (Container as a Service), il ne sera pas aisé de changer de fournisseur. D’autant que les frameworks et les langages de développement supportés par les uns et les autres diffèrent considérablement. Le « serverless » est sans doute l’une des technologies cloud sur lesquelles l’effet « Lockin’ » est le plus fort. Mais les avantages sont suffisamment forts pour compenser le risque induit par cette dépendance accrue.
* Le serverless n’est pas une solution universelle
Soyons clairs, le serverless n’est pas – et ne prétend pas être – la solution universelle à tous vos problèmes. C’est en partie pour cela qu’il propose tant de visages différents. En outre, le concept même du « Function as a Service » convient bien à un certain type de développement : une programmation évènementielle, où l’exécution des fonctionnalités est dictée par le déclenchement d’évènements. Il s’adapte en revanche moins bien à des scénarios plus monolithiques avec des transactions longues et des calculs intensifs ou à des architectures pensées VM ou conteneurs.
Notre saga « Serverless »
Partie 1 : Les différents visages du Serverless Computing
Partie 2 : Atouts et limites du Serverless Computing…
Partie 3 : La gestion des évènements, une brique indispensable au Serverless
A suivre, les principaux runtimes FaaS
