L'informatique sans serveur promet d'inaugurer une ère de mise à l'échelle automatique, une conception logicielle de paiement à l'utilisation qui s'aligne parfaitement sur les modèles commerciaux SaaS. Alors que des obstacles importants subsistent pour les plates-formes de calcul sans serveur, nous pensons que les modèles de conception d'applications sans serveur deviendront monnaie courante dans les prochaines années.
Après des innovations majeures dans le calcul, les progrès de la technologie de stockage suivent généralement peu de temps après. Le passage aux modèles de conception de logiciels sans serveur n'est pas différent, et le stockage doit être prêt pour la suite.
Les promesses de l'informatique sans serveur
Le terme informatique « sans serveur » est clairement un oxymore ; le calcul ne peut pas se faire sans serveurs. Cependant, le matériel peut être si éloigné des développeurs qu'ils ont l'impression que leur code est simplement déployé «automatiquement» dans le cloud, sans jamais avoir à penser à l'infrastructure.
Pour ce faire, les développeurs doivent décomposer leurs applications en une série de fonctions indépendantes et sans état qui sont ensuite exécutées en fonction d'un déclencheur défini par le développeur. Aujourd'hui, chaque fournisseur de cloud propose des déclencheurs faciles à intégrer pour la plupart de leurs services cloud. Par exemple, dans AWS, les développeurs peuvent configurer une fonction à exécuter lorsqu'un l'objet est téléchargé dans un compartiment S3. La possibilité pour les applications tierces de déclencher des fonctions est également disponible via le kit SDK ou l'API AWS. Cela vaut également pour les autres clouds publics.
Où serveurless (actuellement) tombe à court
Ironiquement, les avantages des plates-formes informatiques sans serveur, tels que la possibilité de mettre à l'échelle automatiquement les fonctions sans état de paiement à l'utilisation, sont également au cœur des raisons pour lesquelles l'informatique sans serveur n'a pas encore décollé. Fondamentalement, la plupart des clients sont encore occupés à virtualiser ou à conteneuriser des applications, sans parler de réécritures entières pour les «fonctionnaliser».
Ci-dessus: adoption de la technologie cloud par les entreprises
Pourtant, lorsque des réécritures d'applications se produisent ou lorsque le développement de nouvelles applications commence, les développeurs trouvent souvent qu'il est beaucoup plus difficile d'implémenter des systèmes massivement parallèles composés de fonctions sans état qu'ils ne le pensent initialement. Tout comme le terme « sans serveur », l'informatique « sans état » est aussi un oxymore. Avec les fonctions, l'état peut ne pas être stocké dans la fonction elle-même, mais il est stocké quelque part. C'est généralement dans un stockage partagé tel qu'Amazon S3.
Le problème est que le stockage partagé est lent, les entreprises doivent donc payer le temps nécessaire à l'exécution de la fonction. ainsi que le temps qu'il faut pour stocker et récupérer des données à partir de stockage partagé.
Cela devient plus pénible lorsqu'une fonction est lancée pour la première fois et doit charger toutes les bibliothèques auxquelles le code fait référence. Aujourd'hui, les principales plates-formes Function-as-a-Service (FaaS) doivent charger l'intégralité de la base de code à partir d'une bibliothèque au lieu des seules parties utilisées par la fonction, ce qui entraîne des démarrages à froid téléchargeant des centaines de mégaoctets de bibliothèques de dépendances.
Les développeurs tentent souvent de surmonter les limitations de performances du stockage partagé lent en implémentant l'un des deux anti-modèles. Soit ils créent des caches sur leurs fonctions qui nécessitent un accès rapide aux données, ce qui entraîne un anti-modèle de systèmes à forte répartition avec des caches partout, soit ils tombent dans un anti-modèle «expédier les données au code» où de nombreuses données volumineuses sont reçues transmis de fonction en fonction. Le transfert de beaucoup de données vers le calcul peut être inefficace et rend les fonctions très dépendantes les unes des autres, brisant la promesse d'un système hautement découplé.
L'innovation de stockage est nécessaire
Bien qu'il existe d'autres problèmes avec les plates-formes FaaS, les limitations du stockage partagé lent sont un problème courant dans la conception d'applications sans serveur. Pour permettre l'adoption généralisée de l'informatique sans serveur, un stockage de nouvelle génération présentant les caractéristiques suivantes doit être créé:
- Disponible immédiatement - Cela signifie que le provisionnement du stockage se produit en millisecondes.
- Élastiquement évolutif - Chaque fonction ne devrait pas avoir à provisionner son propre stockage. Au lieu de cela, à mesure que les demandes augmentent et que de nouvelles fonctions sont créées, un référentiel de données central devrait pouvoir se développer pour répondre à la demande.
- Proche pour calculer - Les clients ne veulent pas payer pour le temps passé à interroger ou à stocker des données, le stockage doit donc être aussi proche que possible du calcul.
- Économique pour des charges de travail éclatées - Idéalement, le stockage doit être antifragile du point de vue des coûts. Plus il y a de demande pour un élément de données, plus il devient rapide de le fournir aux utilisateurs.
- Facile d'accès via des applications - Une des raisons Amazon S3 a été conçu pour les applications Web et lancé avec des API et des kits de développement logiciel étonnants. Le stockage utilisé dans l'informatique sans serveur doit être facile d'accès via des fonctions via un SDK de développement et une API faciles à utiliser.
Il sera intéressant de voir comment le stockage répondra à ces besoins. Ce qui n'est pas clair, c'est si les plates-formes existantes peuvent évoluer assez rapidement ou si des produits de stockage entièrement nouveaux devront être créés pour permettre l'informatique sans serveur. Quoi qu'il en soit, l'industrie du stockage est sur le point de subir à nouveau des perturbations massives.