Lorsqu'il s'agit de créer des applications, les développeurs doivent généralement effectuer de nombreuses autres tâches de gestion des serveurs pour déployer leur code, telles que la définition de ressources pour le traitement et le stockage, l'application de correctifs, l'équilibrage de charge, etc. Tous ces éléments supplémentaires entraînent des délais de provisionnement plus longs et des coûts opérationnels supplémentaires qui, à terme, ralentissent les équipes de développement.

L'informatique sans serveur tente d'offrir aux développeurs une expérience invisible "sans serveur", en leur évitant de se préoccuper des serveurs ou de tout autre élément qu'une application pourrait avoir besoin d'exécuter. Le fournisseur de services effectue tout le travail en arrière-plan pour s'assurer que vous disposez des ressources nécessaires pour exécuter votre code et répondre aux exigences, sans que la capacité inutilisée ne vous soit facturée.

Considérez l'informatique sans serveur comme l'approvisionnement en eau chez vous. Vous pourriez creuser votre propre puits, tester la qualité de l'eau, et installer et entretenir toute la plomberie externe nécessaire pour acheminer l'eau jusqu'à la maison. Vous pouvez aussi vous raccorder au réseau d'eau principal de votre ville. Il suffit de tourner le robinet pour obtenir autant d'eau que vous le souhaitez au moment où vous en avez besoin, et la ville vous envoie une facture mensuelle correspondant à la quantité exacte d'eau que vous consommez.

De même, les fournisseurs de services cloud lancent automatiquement les ressources d'infrastructure et les environnements d'exécution nécessaires à l'exécution de vos applications sans serveur, puis les réduisent automatiquement à zéro une fois l'exécution terminée. En général, vous êtes facturé en fonction des ressources utilisées sur la durée d'exécution. Toutefois, cela peut varier selon le service et le fournisseur.

Mais attendez: d'autres types de cloud computing ne fournissent-ils pas de ressources à la demande avec paiement à l'usage? Il est vrai que les modèles de service cloud tels que l'Infrastructure as a Service (IaaS) et le PaaS (Platform as a Service) permettent également un accès à la demande aux ressources informatiques.

Cependant, l'infrastructure cloud qui vous est allouée reste active même si vous ne l'utilisez pas. Vous êtes également responsable du scaling de la capacité du serveur ou de la configuration de vos applications pour qu'elles évoluent à la hausse ou à la baisse en fonction de la demande des utilisateurs.

Les architectures sans serveur sont basées sur des événements. Dans le cadre de ce modèle, le fournisseur ne vous fournit des ressources que lorsqu'un événement déclenche l'exécution de votre code. Il évoluera instantanément et automatiquement en fonction des requêtes.

L'un des principaux inconvénients de l'informatique sans serveur est qu'elle reste une technologie relativement nouvelle. Par conséquent, elle n'est pas encore adaptée à tous les cas d'utilisation potentiels.

Il est également évident que certaines des faiblesses qui existent actuellement seront résolues au fil du temps, à mesure que l'informatique sans serveur continue d'évoluer. En particulier, nous avons déjà beaucoup travaillé sur des implémentations Open Source de solutions sans serveur, et nous cherchons des moyens de rendre les services cloud plus ouverts afin de rendre les solutions portatives sur différents environnements et plates-formes.

• Cas d'utilisation limités : les architectures sans serveur ne sont pas toujours adaptées aux applications ayant des exigences spécifiques, comme les processus de longue durée ou les besoins en latence très faible.
• Contraintes de performances : les fonctions sans serveur peuvent subir des démarrages à froid (retard de l'exécution initiale) et peuvent être soumises à des limites de temps d'exécution et de mémoire.
• Dépendance vis-à-vis d'un fournisseur : la migration d'applications sans serveur d'un fournisseur de services cloud à un autre peut être complexe en raison des différences entre les API et les configurations.
• Visibilité réduite sur les serveurs : les développeurs ne bénéficient que d'une visibilité limitée sur l'infrastructure sous-jacente, ce qui complique la résolution des problèmes de performances ou l'optimisation de l'utilisation des ressources.
• Démarrage lent : les fonctions sans serveur peuvent parfois subir un démarrage à froid qui retarde l'appel de la fonction, ce qui peut avoir un impact sur la latence.