« Serverless » : la traduction littérale de cet anglicisme pourrait laisser penser aux néophytes qu’il s’agit d’une solution « sans serveur » mais il n’en est rien. En réalité, nous avons toujours besoin, à ce jour, de serveurs physiques pour héberger des applications. Dans ce cas, de quoi parle-t-on réellement ?
Dans une architecture serverless, il n’y a plus de notion d’infrastructure en tant que telle. Tout est pris en charge par le fournisseur cloud.
Concrètement, les développeurs conçoivent leur code sous forme de fonctions qui contiennent les informations nécessaires à leur exécution sans se soucier de leur hébergement : voilà pourquoi on parle de serverless.
La technologie serverless se met en œuvre dans les entreprises au travers de deux concepts.
Tout d’abord le Function as a service (FaaS), qui est un modèle de cloud computing qui permet aux utilisateurs de développer des applications et de déployer des fonctionnalités sans gérer de serveur.
Dans le même esprit, le Back end as a service (BaaS) est également un service cloud, qui permet aux développeurs d’externaliser l’arrière-plan d’une application web ou mobile (tels que le stockage, la gestion des bases de données, etc.) traditionnellement géré par l’entreprise.
Les modèles d’applications du serverless sont multiples pour les entreprises.
Par exemple, l’Application Programming Interface (API) est du code des plus simples et plus directs qui renvoie vers une application ou des données à consommer. Elle se compose d’un cadre base web, une bibliothèque, et de code. Avec une architecture serverless, le développeur peut se concentrer exclusivement sur l’écriture et le déploiement du code nécessaire pour servir l’API, sans se soucier du reste.
Ou autre exemple, les webhooks qui sont un outil permettant de récupérer et de stocker les données d’un certain événement. Le cadre « serverless » est bien adapté, car il nécessite peu de code, la surcharge est faible, l’entretien minimum, et la mise à l’échelle automatisée.
Dans une configuration serverless, l’entreprise ne s’occupe que du code. C’est le cloud provider qui est responsable du bon fonctionnement des fonctions serverless tels que l’achat, la maintenance, la scalabilité et ceci quelle que soit la charge de trafic traitée par l’infrastructure.
Par conséquent, tous ces coûts ne sont plus directement à la charge de l’entreprise, on parle alors d’un nouveau mode de tarification cloud « you pay as you go ». L’entreprise paye alors uniquement ce qu’elle consomme.
L’architecture serverless permet aussi aux développeurs d’optimiser le code des applications. En effet, le découpage du code de l’application en « fonctions » permet de répondre au problème d’interdépendance d’une application monolithe. Le fait que l’application soit découpée en différentes fonctions (et que ces fonctions soient indépendantes les unes des autres) permet de faire évoluer l’application par fonctionnalité sans prendre le risque que tout tombe par erreur.
Avec une architecture serverless, très rapidement l’équipe de développement peut déployer de nouvelles fonctionnalités, optimiser le code ou corriger des erreurs, et ce, sans nécessiter de configurations au niveau de l’infrastructure. Ces évolutions ou corrections impactent positivement le time to market de l’entreprise qui peut ainsi rester concurrentielle sur le marché.
Comme mentionné plus haut, le serverless est une façon différente de construire et d’exploiter des systèmes, et comme pour la plupart des alternatives, il y a des limites et aussi des défis.
Le serverless s’appuie entièrement sur un service fourni par un tiers (l’intégration des services de base de données, des services back-end du cloud, etc.), ce qui augmente la dépendance des développements des DSI au fournisseur cloud. Qu’il s’agisse de BaaS, FaaS ou autre, le changement de fournisseur sera difficile, car pour migrer il peut être nécessaire de réécrire le code puisque les langages de développement peuvent être différents. Également, les API qui existent sur une plateforme peuvent ne pas exister sur une autre, et il faut engager de la main-d’œuvre – et donc des surcoûts.
L’usage du serverless a également tendance à augmenter la surface d’attaque en multipliant les points d’accès et les technologies. En outre, ces technologies sont encore relativement peu matures et mal comprises par les responsables de la sécurité et les développeurs, ce qui rend la sécurisation plus complexe. La configuration de déploiement Serverless joue un rôle majeur, car si non sécurisée, les serveurs seront ouverts aux différents types d’attaques (ex : man-in-the-middle). Il faudra aussi bien s’assurer de l’absence de codes malveillants surtout pour les fonctions qui font appel à des dépendances tierces afin d’éviter de mettre les données en danger.
Enfin, l’architecture serverless est censée simplifier toutes les phases de déploiement, mais reste assez complexe pour les tests. S’il est relativement facile de tester les fonctions individuelles des applications, tester l’infrastructure et les combinaisons de toutes les fonctions devient beaucoup plus difficile à la suite de cette complexité. Dans ce cas, il faut mettre en place des procédures pour arrêter au préalable les services générateurs ce qui posera des problèmes d’organisation, de rollback en cas de soucis, et de disponibilité des services que le serverless ne pourra pas résoudre seul.
Il est recommandé de supprimer les dépendances inutiles. La surveillance et la mise à jour continue des versions du framework, des bibliothèques et des autres, ainsi que la création de correctifs de sécurité pour les anciennes versions des dépendances, doivent être une priorité.
Chiffrer toutes les données et utiliser un stockage sécurisé pour les informations d’identification. Examiner les rôles et les autorisations accordés aux utilisateurs, aux tiers et aux fonctions de l’application.
Une façon d’empêcher l’injection de données dans les applications serverless est de séparer les données des fonctions en utilisant des passerelles API. Les données étant récupérées à partir d’un large éventail de sources, la passerelle agira comme un tampon de sécurité, créant une séparation entre les utilisateurs de l’application côté client et les fonctions serverless côté back. Cela réduit les attaques en fournissant plusieurs contrôles de sécurité à l’aide d’un proxy inverse.
Tous droits réservés, Copyright 2007 – 2022, TechTarget
