Points clés
- Depuis plusieurs années maintenant, on nous promet que l'informatique sans serveur (serverless) ouvrira une nouvelle ère sans OS spécifique pour faire tourner les applications. On nous a dit qu'une telle structure résoudrait beaucoup de problèmes d'évolutivité. En fait, tout est différent.
- Alors que beaucoup voient la technologie sans serveur comme une nouvelle idée, ses racines remontent à 2006 avec Zimki PaaS et Google App Engine, qui utilisent tous deux une architecture sans serveur.
- Il y a quatre raisons pour lesquelles la révolution sans serveur est au point mort, de la prise en charge limitée des langages de programmation aux problèmes de performances.
- L'informatique sans serveur n'est pas si inutile. Loin de là. Cependant, ils ne doivent pas être considérés comme un remplacement direct des serveurs. Pour certaines applications, ils peuvent être un outil pratique.
Le serveur est mort, vive le serveur !
C'est le cri de guerre des partisans de la révolution sans serveur. Un rapide coup d'œil à la presse industrielle de ces dernières années suffit pour conclure que le modèle de serveur traditionnel est mort et que dans quelques années, nous utiliserons tous des architectures sans serveur.
Comme tout le monde dans l'industrie le sait, et comme nous l'avons également souligné dans notre article sur , c'est faux. Malgré de nombreux articles sur le fond , cela n'a jamais eu lieu. En fait, que cette révolution est peut-être dans une impasse.
Certaines des promesses des modèles sans serveur se sont certainement réalisées, mais pas toutes. Pas tout le monde.
Dans cet article, je veux examiner les raisons de cette condition. Pourquoi le manque de flexibilité des modèles sans serveur est toujours un obstacle à leur adoption plus large, bien qu'ils restent utiles dans des circonstances spécifiques et bien définies.
Ce que les adeptes de l'informatique sans serveur ont promis
Avant de passer aux problèmes de l'informatique sans serveur, voyons ce qu'ils avaient à fournir. étaient nombreux et - parfois - très ambitieux.
Pour ceux qui ne connaissent pas le terme, voici une brève définition. L'informatique sans serveur définit une architecture dans laquelle les applications (ou parties d'applications) s'exécutent à la demande dans des environnements d'exécution généralement hébergés à distance. De plus, des systèmes sans serveur peuvent être hébergés. La construction de systèmes sans serveur robustes a été une préoccupation majeure des administrateurs système et des entreprises SaaS au cours des dernières années, car (on le prétend) cette architecture offre plusieurs avantages clés par rapport au modèle client/serveur "traditionnel":
- Les modèles sans serveur n'obligent pas les utilisateurs à gérer leurs propres systèmes d'exploitation ni même à créer des applications compatibles avec des systèmes d'exploitation spécifiques. Au lieu de cela, les développeurs créent du code partagé, le téléchargent sur une plate-forme sans serveur et le regardent s'exécuter.
- Les ressources dans les frameworks sans serveur sont généralement facturées à la minute (voire à la seconde). Cela signifie que les clients ne paient que pour le temps pendant lequel ils exécutent réellement le code. Cela se compare favorablement à la machine virtuelle cloud traditionnelle, où la machine est inactive la plupart du temps, mais vous devez payer pour cela.
- Le problème de l'évolutivité a également été résolu. Les ressources des frameworks sans serveur sont affectées dynamiquement afin que le système puisse facilement faire face aux pics soudains de la demande.
En bref, les modèles sans serveur offrent des solutions flexibles, peu coûteuses et évolutives. Je suis surpris que nous n'ayons pas pensé à cette idée plus tôt.
Est-ce vraiment une nouvelle idée ?
En fait, l'idée n'est pas nouvelle. Le concept permettant aux utilisateurs de payer uniquement pour le temps d'exécution du code existe depuis son introduction sous la 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 la plupart des technologies désormais appelées « nuages natives » qui fournissent presque la même chose. Comme indiqué, les modèles sans serveur ne sont essentiellement qu'une extension du modèle commercial SaaS qui existe depuis des décennies.
Il convient également de reconnaître que le modèle sans serveur n'est pas une architecture FaaS, bien qu'il existe un lien entre les deux. Le FaaS est essentiellement la partie centrée sur le calcul d'une architecture sans serveur, mais il ne représente pas l'ensemble du système.
Alors pourquoi tout ce battage médiatique ? Eh bien, alors que le taux de pénétration d'Internet dans les pays en développement continue de monter en flèche, la demande de ressources informatiques augmente également. Par exemple, de nombreux pays dont les secteurs du commerce électronique connaissent une croissance rapide ne disposent tout simplement pas de l'infrastructure informatique pour les applications sur ces plates-formes. C'est là qu'interviennent les plateformes payantes sans serveur.
Problèmes avec les modèles sans serveur
Le hic, c'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 eux-mêmes ou qu'ils n'apportent pas de valeur significative à certaines entreprises dans certaines circonstances. Mais l'affirmation principale de la "révolution" - que l'architecture sans serveur remplacera rapidement l'architecture traditionnelle - ne se concrétise jamais.
Voilà pourquoi.
Prise en charge limitée des langages de programmation
La plupart des plates-formes sans serveur n'autorisent l'exécution que des applications écrites dans certains langages. Cela limite considérablement la flexibilité et l'adaptabilité de ces systèmes.
Les plates-formes sans serveur sont considérées comme prenant en charge la plupart des principaux langages. AWS Lambda et Azure Functions fournissent également un wrapper pour l'exécution d'applications et de fonctions dans des langages non pris en charge, bien que cela ait souvent un coût en termes de performances. Donc, pour la plupart des organisations, cette limitation n'est généralement pas un gros problème. Mais voici la chose. L'un des avantages des modèles sans serveur est censé être que les programmes obscurs et peu utilisés peuvent être utilisés à moindre coût, car vous ne payez que pour le temps d'exécution. Et les programmes obscurs et rarement utilisés sont souvent écrits dans des langages de programmation obscurs et rarement utilisés.
Cela sape l'un des principaux avantages du modèle sans serveur.
Liaison avec un fournisseur
Le deuxième problème avec les plates-formes sans serveur, ou du moins 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 standardisation en termes de fonctions d'écriture, de déploiement et de gestion. Cela signifie que la migration des fonctionnalités d'une plate-forme à une autre prend énormément de temps.
La partie la plus difficile du passage à un modèle sans serveur ne concerne pas les fonctionnalités de calcul, qui ne sont généralement que des extraits de code, mais la façon dont les applications communiquent avec les 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 pas le reste de l'application. C'est exactement le contraire des plates-formes bon marché et flexibles promises.
Certains affirment que les modèles sans serveur sont nouveaux et qu'il n'y a pas eu le temps de normaliser leur fonctionnement. Mais ils ne sont pas si nouveaux, comme je l'ai noté ci-dessus, et de nombreuses autres technologies cloud telles que les conteneurs sont déjà devenues beaucoup plus pratiques en raison du développement et de l'adoption généralisée de bonnes normes.
Performance
Les performances informatiques des plates-formes sans serveur sont difficiles à mesurer, en partie parce que les fournisseurs ont tendance à garder les informations secrètes. La plupart affirment que les fonctionnalités sur les plates-formes distantes sans serveur fonctionnent aussi rapidement que sur les serveurs internes, à l'exception de quelques problèmes de latence inévitables.
Cependant, certaines preuves suggèrent le contraire. Les fonctions qui n'ont pas été exécutées auparavant sur une plate-forme particulière, ou qui n'ont pas été exécutées depuis un certain temps, mettent un certain temps à s'initialiser. Cela est probablement dû au fait que leur code a été porté sur un support de stockage moins accessible, bien que, comme pour les références, la plupart des fournisseurs ne vous parlent pas du portage des données.
Bien sûr, il existe plusieurs façons de contourner cela. L'une consiste à optimiser les fonctionnalités pour le langage cloud sur lequel votre plate-forme sans serveur s'exécute, mais cela sape quelque peu l'affirmation selon laquelle ces plates-formes sont "agiles".
Une autre approche consiste à s'assurer que les programmes critiques pour les performances s'exécutent régulièrement pour les garder "frais". Cette deuxième approche, bien sûr, va un peu à l'encontre de l'affirmation selon laquelle les plates-formes sans serveur sont plus rentables car vous ne payez que pour le temps d'exécution de vos programmes. Les fournisseurs de cloud ont introduit de nouvelles façons de réduire les lancements à froid, mais beaucoup d'entre eux nécessitent une "mise à l'échelle à un", ce qui sape la valeur d'origine du FaaS.
Le problème du démarrage à froid peut être en partie résolu en exécutant des systèmes sans serveur en interne, mais cela a ses propres frais et reste une option de niche pour les équipes disposant de ressources suffisantes.
Vous ne pouvez pas exécuter des applications entières
Enfin, la raison peut-être la plus importante pour laquelle les architectures sans serveur ne remplaceront pas de sitôt les modèles traditionnels est qu'elles ne peuvent (généralement) pas exécuter des applications entières.
Plus précisément, il est peu pratique d'un point de vue coût. Votre monolithe réussi ne devrait probablement pas ê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é aux nouveaux développements. Pratiquement aucune application (architecture) existante ne peut être portée. Vous pouvez migrer, mais vous devez repartir de zéro.
Cela signifie que dans la grande majorité des cas, les plates-formes sans serveur sont utilisées en complément des serveurs principaux pour effectuer des tâches de calcul intensives. Ceci est très différent des deux autres formes de cloud computing, les conteneurs et les machines virtuelles, qui offrent une manière holistique d'effectuer l'informatique à distance. Cela illustre l'un des défis de la migration 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 votre propre matériel peut apporter des avantages réels et durables à de nombreuses organisations. Mais si certaines applications se trouvent sur des serveurs internes et d'autres sur des architectures cloud sans serveur, la gestion entre alors dans un nouveau niveau de complexité.
Vive la révolution?
Malgré toutes ces plaintes, je ne suis pas opposé aux solutions sans serveur en soi. Honnêtement. C'est juste que les développeurs doivent comprendre - surtout s'ils explorent des modèles sans serveur pour la première fois - que cette technologie ne remplace pas directement les serveurs. Consultez plutôt nos conseils et ressources sur et décider de la meilleure façon d'appliquer ce modèle.
Source: habr.com