Points clés
- Depuis plusieurs années, on nous promet que l'informatique sans serveur (serverless) ouvrira une nouvelle ère sans système d'exploitation spécifique pour exécuter des applications. On nous a dit que cette structure résoudrait de nombreux problèmes de scalabilité. En réalité, tout est différent.
- Bien que beaucoup considèrent la technologie sans serveur comme une nouvelle idée, ses racines peuvent être retracées jusqu'en 2006, lorsque sont apparues Zimki PaaS et Google App Engine — dans les deux cas, une architecture sans serveur est utilisée.
- Il y a quatre raisons pour lesquelles la révolution sans serveur a été confrontée à un mur : du support limité des langages de programmation aux problèmes de performance.
- L'informatique sans serveur n'est pas si inutile. Pas du tout. Cependant, elle ne doit pas être considérée comme un remplacement direct des serveurs. Pour certaines applications, elle peut être un outil pratique.
Le serveur est mort, vive le serveur !
Tel est le cri de guerre des partisans de la révolution sans serveur. Il suffit de consulter rapidement la presse sectorielle de ces dernières années pour conclure facilement que le modèle de serveur traditionnel est mort et que dans quelques années, nous utiliserons tous des architectures sans serveur.
Comme le sait toute personne dans le secteur, et comme nous l'avons également indiqué dans notre article sur , ce n'est pas le cas. Malgré de nombreuses publications sur les avantages de la , elle ne s'est pas matérialisée. En réalité, , que cette révolution est peut-être confrontée à une impasse.
Certaines des promesses faites pour les modèles sans serveur ont sans aucun doute été réalisées, mais pas toutes. Loin de là.
Dans cet article, je souhaite examiner les raisons de cet état de fait. Pourquoi le manque de flexibilité des modèles sans serveur reste un obstacle à leur adoption plus large, même s'ils restent utiles dans des circonstances spécifiques et bien définies.
Ce que les partisans de l'informatique sans serveur ont promis
Avant d'aborder les problèmes de l'informatique sans serveur, examinons ce qu'ils étaient censés fournir. étaient nombreuses et par moments très ambitieuses.
Pour ceux qui ne connaissent pas le terme, voici une brève définition. Le calcul sans serveur définit une architecture où les applications (ou parties d'applications) s'exécutent à la demande dans des environnements d'exécution, qui sont généralement hébergés à distance. De plus, les systèmes sans serveur peuvent être hébergés localement. Au cours des dernières années, la création de systèmes sans serveur robustes a été la principale préoccupation des administrateurs système et des entreprises SaaS, car (il est affirmé) cette architecture offre plusieurs avantages clés par rapport au modèle « traditionnel » client-serveur :
- Les modèles sans serveur ne nécessitent pas que les utilisateurs gèrent leurs propres systèmes d'exploitation ou même créent des applications compatibles avec des systèmes d'exploitation spécifiques. Au lieu de cela, les développeurs créent un code commun, le téléchargent sur une plateforme sans serveur et observent son exécution.
- Les ressources dans les cadres sans serveur sont généralement facturées à la minute (ou même à la seconde). Cela signifie que les clients ne paient que pour le temps où leur code est effectivement exécuté. C'est un avantage considérable par rapport à une VM cloud traditionnelle, où la machine reste souvent inactive, mais pour laquelle il faut continuer à payer.
- Le problème de la scalabilité a également été résolu. Les ressources dans les cadres sans serveur sont attribuées dynamiquement, de sorte que le système gère facilement les pics soudains de demande.
En résumé, les modèles sans serveur offrent des solutions flexibles, économiques et évolutives. C'est incroyable que nous n'ayons pas pensé à cette idée plus tôt.
Est-ce vraiment une nouvelle idée ?
En réalité, l'idée n'est pas nouvelle. La conception qui permet aux utilisateurs de ne payer que pour le temps où le code est effectivement exécuté existe depuis lors qu'elle a été introduite dans le cadre de en 2006, et à peu près à la même époque, Google App Engine a proposé une solution très similaire.
En fait, ce que nous appelons maintenant le modèle « sans serveur » est plus ancien que de nombreuses technologies que l'on qualifie aujourd'hui de « cloud natif », et qui offrent presque la même chose. Comme cela a été noté, les modèles sans serveur ne sont en fait qu'une extension du modèle économique SaaS, qui existe depuis plusieurs décennies.
Il est également important de reconnaître que le modèle sans serveur n'est pas l'architecture FaaS, bien qu'il y ait un lien entre les deux. FaaS est en essence une partie orientée vers le calcul de l'architecture sans serveur, mais elle ne représente pas le système dans son ensemble.
Alors, pourquoi tout ce bruit ? Eh bien, alors que la vitesse de pénétration d'Internet dans les pays en développement continue de croître rapidement, la demande en ressources de calcul augmente également. Par exemple, dans de nombreux pays avec des secteurs de commerce électronique en forte croissance, il n'y a tout simplement pas d'infrastructure informatique pour les applications sur ces plateformes. C'est ici que les plateformes sans serveur payantes entrent en jeu.
Problèmes des modèles sans serveur
Le problème est que les modèles sans serveur ont... des problèmes. Ne vous méprenez pas : je ne dis pas qu'ils sont mauvais en soi ou qu'ils n'apportent pas de valeur significative pour certaines entreprises dans certaines circonstances. Mais l'affirmation principale de la « révolution » - que l'architecture sans serveur remplacera rapidement la traditionnelle - ne se réalisera jamais.
Voici pourquoi.
Support limité pour les langages de programmation
La plupart des plateformes sans serveur ne permettent d'exécuter que des applications écrites dans certains langages. Cela limite gravement la flexibilité et l'adaptabilité de ces systèmes.
Il est généralement admis que les plateformes sans serveur prennent en charge la plupart des langages principaux. AWS Lambda et Azure Functions fournissent également une interface pour exécuter des applications et des fonctions dans des langages non pris en charge, bien que cela implique souvent des coûts en matière de performance. Donc, pour la plupart des organisations, cette limitation n'est généralement pas très significative. Mais voici le problème. L'un des avantages supposés des modèles sans serveur est que les programmes peu connus et rarement utilisés peuvent être exécutés à moindre coût, car vous ne payez que pour le temps d'exécution. Or, ces programmes peu connus sont souvent écrits dans... des langages de programmation peu connus et rarement utilisés.
Cela compromet l'un des principaux avantages du modèle sans serveur.
Dépendance au fournisseur
Le deuxième problème avec les plateformes sans serveur, ou du moins avec la façon dont elles sont actuellement mises en œuvre, est qu'elles ne se ressemblent généralement pas au niveau opérationnel. Il n'y a pratiquement aucune normalisation en ce qui concerne l'écriture des fonctions, le déploiement et la gestion. Cela signifie que la migration de fonctions d'une plateforme à une autre prend énormément de temps.
La partie la plus difficile de la transition vers un modèle sans serveur n'est pas les fonctions de calcul, qui sont généralement juste des fragments de code, mais la manière dont les applications sont liées aux systèmes connectés, tels que le stockage d'objets, la gestion des identités et les files d'attente. Les fonctions peuvent être déplacées, mais le reste de l'application ne le peut pas. C'est l'exact opposé des plateformes bon marché et flexibles promises.
Certains affirment que les modèles sans serveur sont apparus récemment et qu'il n'y a pas eu de temps pour normaliser leur fonctionnement. Mais ils ne sont pas aussi récents que je l'ai déjà mentionné, et de nombreuses autres technologies cloud, comme les conteneurs, sont déjà devenues beaucoup plus conviviales grâce à l'élaboration et à la large adoption de bonnes normes.
Performance
La performance de calcul des plateformes sans serveur est difficile à mesurer, en partie parce que les fournisseurs s'efforcent de garder les informations secrètes. La plupart affirment que les fonctions sur des plateformes sans serveur distantes fonctionnent aussi rapidement que sur des serveurs internes, à l'exception de quelques problèmes de latence inévitables.
Cependant, des faits isolés indiquent le contraire. Les fonctions qui n'étaient pas précédemment exécutées sur une plateforme donnée ou qui n'avaient pas été exécutées depuis un certain temps nécessitent un certain temps d'initialisation. Cela est probablement dû au fait que leur code a été déplacé sur un support de données moins accessible, bien que, comme pour les benchmarks, la plupart des fournisseurs ne vous parleront pas du transfert de données.
Bien sûr, il existe plusieurs façons de contourner cela. L'une d'entre elles consiste à optimiser les fonctions pour tout langage cloud sur lequel votre plateforme sans serveur fonctionne, mais cela compromet un peu l'affirmation selon laquelle ces plateformes sont "flexibles".
Une autre approche consiste à garantir l'exécution régulière des programmes critiques pour la performance, afin qu'ils restent « frais ». Cette seconde approche contredit quelque peu l'affirmation selon laquelle les plateformes sans serveur sont plus économiques, car vous ne payez que pour le temps d'exécution de vos programmes. Les fournisseurs de cloud ont mis en place de nouvelles méthodes pour réduire les démarrages à froid, mais beaucoup d'entre elles nécessitent un « passage à un » (scale to one), ce qui compromet la valeur initiale du FaaS.
Le problème du « démarrage à froid » peut être partiellement résolu en exécutant des systèmes sans serveur par ses propres moyens, mais cela implique des coûts supplémentaires et reste une option de niche pour des équipes bien dotées en ressources.
Vous ne pouvez pas exécuter des applications entières
Enfin, peut-être la raison la plus importante pour laquelle les architectures sans serveur ne remplaceront pas les modèles traditionnels de sitôt : elles ne peuvent (en général) pas exécuter d'applications entières.
Plus précisément, cela n'est pas rentable. Votre monolithe réussi ne vaut probablement pas la peine d'être transformé en un ensemble de quatre douzaines de fonctions liées par huit passerelles, quarante files d'attente et une douzaine d'instances de base de données. Pour cette raison, le serverless est mieux adapté pour de nouvelles développements. Pratiquement aucune application existante (architecture) ne peut être migrée. Vous pouvez migrer, mais vous devrez recommencer à zéro.
Cela signifie que dans la grande majorité des cas, les plateformes sans serveur sont utilisées comme un complément aux serveurs internes pour exécuter des tâches nécessitant des calculs lourds. Cela les distingue fortement des deux autres formes de technologies cloud - conteneurs et machines virtuelles - qui offrent une manière intégrée d'effectuer des calculs distants. Cela illustre l'une des difficultés de la transition des microservices vers des systèmes sans serveur.
Bien sûr, ce n'est pas toujours un problème. La possibilité d'utiliser périodiquement d'énormes ressources informatiques sans acheter son propre matériel peut apporter un réel et durable avantage à de nombreuses organisations. Mais si certaines applications sont sur des serveurs internes et d'autres sur des architectures cloud sans serveur, la gestion devient d'un niveau de complexité supérieur.
Vive la révolution ?
Malgré toutes ces plaintes, je ne suis pas opposé aux solutions sans serveur en tant que telles. Honestement. Les développeurs doivent simplement comprendre — surtout s'ils explorent des modèles sans serveur pour la première fois — que cette technologie n'est pas un remplacement direct des serveurs. Consultez plutôt nos conseils et ressources sur et décidez comment appliquer ce modèle de la meilleure manière.
Source : habr.com
