La configuration sans serveur ne se limite pas à une fonction en tant que service (FaaS), c’est un service de cloud computing qui permet aux développeurs d’exécuter du code ou des conteneurs en réponse à des événements ou à des demandes spécifiques sans spécifier ni gérer l’infrastructure requise pour exécuter le code.

Le FaaS est le modèle informatique au cœur de l’approche sans serveur, et les deux termes sont souvent utilisés de manière interchangeable. Le modèle sans serveur est un ensemble de services capables de répondre à des événements ou à des demandes spécifiques et de s’arrêter totalement (« scale to zero ») lorsqu’ils ne sont plus utilisés, et dont le provisionnement, la gestion et la facturation sont gérés par le fournisseur de cloud, restant ainsi invisibles pour les développeurs.

Outre le FaaS, ces services incluent des bases de données et du stockage, des passerelles d’interface de programmation des applications (API) et une architecture pilotée par les événements.

Les bases de données (SQL et NoSQL) et le stockage (en particulier le stockage d’objets) sont le fondement de la couche de données. Une approche sans serveur de ces technologies implique de passer d’un provisionnement d’« instances » avec une capacité définie, des limites de connexions et de requêtes, à des modèles mis à l’échelle de façon linéaire selon la demande, tant au niveau de l’infrastructure que de la tarification.

Les passerelles API agissent comme des proxys pour les actions des applications Web et fournissent le routage des méthodes HTTP, l’identification et les secrets du client, les limites de débit, le CORS (partage de ressources inter-origines), la visualisation de l’utilisation des API, la visualisation des journaux de réponse et les règles de partage des API.

Les architectures sans serveur fonctionnent parfaitement pour les workloads axées sur les événements et le traitement des flux, l’exemple par excellence étant la plateforme open-source de transmission d’événements en continu Apache Kafka.

Les fonctions automatisées sans serveur sont sans état et conçues pour gérer des événements individuels. Ces fonctions font désormais partie intégrante de l’architecture orientée événements (« Event-driven Architecture » ou EDA), un modèle de conception logicielle qui s’articule autour de la publication, de la capture, du traitement et du stockage des événements. Dans un cadre EDA, les producteurs d’événements (comme les microservices, les API, les appareils IoT) envoient des notifications d’événements en temps réel aux consommateurs d’événements, ce qui active des routines de traitement spécifiques. Par exemple, lorsque Netflix publie une nouvelle série originale, plusieurs services EDA attendent la notification de publication, ce qui déclenche une cascade de mises à jour pour informer les utilisateurs. De nombreuses autres entreprises basées sur des applications web et mobiles dédiées aux utilisateurs (comme Uber, DoorDash et Instacart) s’appuient sur une architecture orientée événements.

Le sans serveur, le PaaS (plateforme en tant que service), les conteneurs et les machines virtuelles (VM) jouant tous un rôle critique dans le développement d’applications cloud et l’écosystème de calcul, il est utile de comparer certaines de leurs caractéristiques clés.

• Temps de provisionnement : se mesure en millisecondes pour le sans serveur, contre quelques minutes à quelques heures pour les autres modèles.

• Charge administrative : aucune pour le serverless, contre une charge croissante pour le PaaS, les conteneurs et les VM, respectivement.

• Maintenance : les architectures sans serveur sont entièrement gérées par les CSP. Il en va de même pour les PaaS, mais les conteneurs et les machines virtuelles nécessitent une maintenance importante, notamment la mise à jour et la gestion des systèmes d’exploitation, des images de conteneurs, des connexions, et plus encore.

• Mise à l’échelle : l’auto-scaling (notamment l’auto-scaling to zero) est instantané et inhérent à l’approche sans serveur. Les autres modèles offrent une mise à l’échelle automatique mais lente qui nécessite un réglage minutieux des règles d’auto-scaling, et aucun scaling to zero.

• Planification des capacités : aucune pour le sans serveur, alors que les autres modèles requièrent un mélange d’évolutivité automatique et de planification des capacités.

• Sans état : inhérent à l’approche sans serveur, ce qui signifie que l’évolutivité n’est jamais un problème ; l’état est maintenu dans un service ou des ressources externes. Les PaaS, les conteneurs et les machines virtuelles peuvent exploiter le protocole HTTP, maintenir un socket ou une connexion ouverte pendant de longues périodes et stocker l’état en mémoire entre les appels.

• Haute disponibilité (« High Availability » ou HA) et reprise après sinistre (« Disaster Recovery » ou DR) : le sans serveur offre à la fois une haute disponibilité et une reprise après sinistre sans effort ni frais supplémentaires. À l’inverse, les autres modèles représentent des coûts et des efforts de gestion supplémentaires. Avec les machines virtuelles et les conteneurs, l’infrastructure peut être redémarrée automatiquement.

• Utilisation des ressources : le sans serveur est 100 % efficace, car il n’y a pas de capacité inactive. Il est invoqué uniquement sur demande. Tous les autres modèles présentent au moins un certain degré de fonctionnement à vide.

• Facturation et économies : le serverless est mesuré en unités de 100 millisecondes. Les PaaS, les conteneurs et les machines virtuelles sont généralement mesurés à l’heure ou à la minute.

Kubernetes est une plateforme d’orchestration de conteneurs open source qui automatise le déploiement, la gestion et la mise à l’échelle des conteneurs. Cette automatisation simplifie considérablement le développement d’applications conteneurisées.

Les applications sans serveur sont souvent déployées dans des conteneurs. Cependant, Kubernetes ne peut exécuter des applications sans serveur de manière indépendante qu’avec un logiciel spécialisé qui intègre Kubernetes à la plateforme sans serveur d’un fournisseur de cloud donné.

Knative est une extension open source qui fournit un cadre sans serveur pour Kubernetes. Elle permet à n’importe quel conteneur de s’exécuter en tant que workload serverless sur n’importe quelle plateforme cloud exécutant Kubernetes, que le conteneur soit conçu autour d’une fonction serverless ou d’un autre code d’application (par exemple, microservices). Knative fonctionne en faisant abstraction du code et en gérant le routage réseau, les déclencheurs d’événements et l’auto-scaling pour une exécution sans serveur.

Knative est transparent pour les développeurs. Ils n’ont qu’à créer un conteneur en utilisant Kubernetes, et Knative fait le reste, en exécutant le conteneur comme un workload sans serveur.

L’informatique sans serveur offre aux développeurs individuels et aux équipes de développement d’entreprise de nombreux avantages techniques et commerciaux :

• Amélioration de la productivité des développeurs : comme indiqué plus haut, le sans serveur permet aux équipes de développement de se concentrer sur l’écriture du code, et non sur la gestion de l’infrastructure. Les développeurs disposent ainsi de beaucoup plus de temps pour innover et optimiser les fonctionnalités de leurs applications front-end et leur logique métier.

• Facturation limitée à l’exécution : le compteur démarre lorsque la requête est formulée et s’arrête lorsque l’exécution est terminée. En comparaison, l’IaaS est un modèle informatique dans lequel les clients payent pour les serveurs physiques, les machines virtuelles et d’autres ressources nécessaires au fonctionnement des applications, depuis le provisionnement de ces ressources jusqu’à leur mise hors service explicite.

• Développement dans n’importe quel langage : le sans serveur est un environnement « polyglotte » qui permet aux développeurs de coder dans n’importe quel langage ou framework : Java, Python, JavaScript ou node.js.

• Rationalisation des cycles de développement/DevOps : le serverless simplifie le déploiement et, de façon plus large, le DevOps, car les développeurs ne passent pas de temps à définir l’infrastructure nécessaire pour intégrer, tester, livrer et déployer des versions de code en production.

• Performances rentables : pour des workloads spécifiques (par exemple, un traitement parfaitement parallèle, le traitement de flux, certaines tâches de traitement de données), l’informatique sans serveur peut être à la fois plus rapide et plus rentable que d’autres formes de calcul.

• Une latence réduite : dans un environnement sans serveur, le code peut s’exécuter plus près de l’utilisateur final, ce qui réduit la latence.

• Visibilité de l’utilisation : les plateformes sans serveur offrent une visibilité quasi-totale sur les temps système et utilisateur et peuvent agréger les informations d’utilisation de manière systématique.

Bien que l’approche sans serveur présente de nombreux avantages, il est essentiel de prendre en compte certains inconvénients :

• Moins de contrôle : dans un cadre sans serveur, l’organisation confie le contrôle des serveurs à un CSP tiers, renonçant ainsi à la gestion du matériel et des environnements d’exécution.

• L’enfermement propriétaire : chaque fournisseur de services offre des capacités et des fonctionnalités sans serveur uniques, qui sont incompatibles avec les autres fournisseurs.

• Démarrage lent : également appelé « démarrage à froid », le démarrage lent peut affecter les performances et la réactivité des applications sans serveur, en particulier dans les environnements à la demande en temps réel. 

• Tests et débogage complexes : le débogage peut être plus compliqué avec un modèle informatique sans serveur car les développeurs manquent de visibilité sur les processus back-end.

• Coût plus élevé pour exécuter des applications pendant de longues périodes : les modèles d’exécution sans serveur ne sont pas conçus pour exécuter du code de façon prolongée. Par conséquent, les processus de longue durée peuvent coûter plus cher que s’ils étaient exécutés dans des environnements traditionnels de serveurs dédiés ou de machines virtuelles.

Grâce à ses caractéristiques et avantages unique, l’architecture sans serveur est particulièrement adaptée aux cas d’utilisation autour des microservices, des back-ends mobiles, et du traitement des données et des flux d’événements.

Aujourd’hui, le cas d’utilisation le plus courant du modèle sans serveur est la prise en charge des architectures de microservices. Le modèle microservice est axé sur la création de petits services qui effectuent une tâche unique et communiquent entre eux à l’aide d’API. Bien que les microservices puissent également être créés et exploités à l’aide d’un PaaS ou de conteneurs, le modèle serverless a pris beaucoup d’ampleur en raison de ses caractéristiques autour de petits bouts de code, d’une mise à l’échelle inhérente et automatique, d’un provisionnement rapide et d’un modèle de tarification qui ne facture pas le fonctionnement à vide.

Toute action (ou fonction) dans une plateforme sans serveur peut être transformée en point de terminaison HTTP prêt à être consommé par les clients web. Lorsqu’elles sont activées pour le web, ces actions sont appelées actions web. Lorsque vous avez des actions web, vous pouvez les assembler en une API complète dotée d’une passerelle d’API, qui renforce la sécurité et offre la prise en charge d’OAuth, la limitation du débit et la prise en charge des domaines personnalisés.

Open Liberty InstantOn⁴ adopte une nouvelle approche pour soutenir le démarrage rapide des applications sans serveur. Avec InstantOn, vous pouvez prendre un point de contrôle de votre processus d’application Java en cours d’exécution pendant le développement de l’application, puis restaurer ce point de contrôle en production. La restauration est rapide (quelques centaines de millisecondes), ce qui la rend idéale pour les applications sans serveur. Étant donné qu’InstantOn est un point de contrôle de votre application existante, son comportement après la restauration est identique, proposant notamment la même qualité de performance en termes de débit. Ce processus permet aux organisations d’adopter le serverless pour de nouvelles applications cloud natives et offre la possibilité d’apporter le serverless à l’entreprise existante.

Le sans serveur est particulièrement adapté aux tâches liées à l’enrichissement, à la transformation, à la validation et au nettoyage de données structurées (texte, audio, image et vidéo). Les développeurs peuvent également y recourir pour le traitement des PDF, la normalisation audio, le traitement des images (rotation, accentuation, réduction du bruit, génération de vignettes), la reconnaissance optique de caractères (OCR) et le transcodage vidéo.

Tout type de tâche parfaitement parallèle est un cas d’utilisation idéal pour une exécution sans serveur, chaque tâche parallélisable donnant lieu à une invocation d’action. Pour donner quelques exemples de tâches, citons la recherche et le traitement des données (en particulier le Cloud Object Storage), les opérations MapReduce et le web scraping, l’automatisation des processus métier, l’optimisation des hyperparamètres, les simulations Monte Carlo et le traitement du génome.

L’association Apache Kafka géré avec FaaS et base de données ou stockage offre une base solide pour la construction en temps réel de pipelines de données et d’applications de streaming. Ces architectures sont idéales pour travailler avec toutes sortes d’entrées de flux de données (pour la validation, le nettoyage, l’enrichissement, la transformation), y compris les flux de données des capteurs IdO, des journaux d’application, des marchés financiers et des entreprises (provenant d’autres sources de données).

L’approche sans serveur offre l’évolutivité automatisée nécessaire à l’exécution des workloads d’intelligence artificielle (IA) et de machine learning (ML), ce qui garantit des performances optimales et accélère l’innovation.

L’informatique sans serveur prend en charge une stratégie de cloud hybride en offrant l’agilité, la flexibilité et l’évolutivité nécessaires pour s’adapter aux workloads fluctuantes dans les environnements sur site, dans le cloud public, dans le cloud privé et en périphérie .

Le sans serveur prend en charge un grand nombre des applications les plus courantes d’aujourd’hui, notamment la gestion de la relation client (CRM), le calcul haute performance (« High-performance Computing » ou HPC), l’analyse du big data, l’automatisation des processus métier, le streaming vidéo, le gaming, la télémédecine, le commerce numérique, la création de chatbots et bien d’autres encore.