Points clés
- Depuis plusieurs années maintenant, on nous promet que l'informatique sans serveur inaugurera une nouvelle ère sans OS spécifique pour exécuter des applications. On nous a dit qu'une telle structure résoudrait de nombreux problèmes d'évolutivité. En fait, tout est différent.
- Alors que beaucoup considèrent le sans serveur comme une nouvelle idée, ses racines remontent à 2006, lorsque Zimki PaaS et Google App Engine ont été introduits, tous deux utilisant 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. Pas du tout. 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 adeptes de la révolution sans serveur. En jetant un coup d’œil rapide sur la presse industrielle de ces dernières années, il est facile de 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 le sait, et comme nous l'avons également souligné dans notre article sur l' état de l'informatique sans serveur , ce n'est pas le cas. Malgré de nombreux articles sur les mérites de la révolution sans serveur , elle ne s'est jamais concrétisée . En fait, des recherches récentes suggèrent que cette révolution est peut-être dans une impasse.
Certaines des promesses pour les modèles sans serveur ont sans aucun doute été réalisées, mais pas toutes. Pas tout le monde.
Dans cet article, je souhaite examiner les raisons de cette condition. Pourquoi le manque de flexibilité des modèles sans serveur est toujours un obstacle à leur adoption plus large, même s'ils restent utiles dans des circonstances spécifiques et bien définies.
Ce que les défenseurs de l'informatique sans serveur ont promis
Avant d'aborder les problèmes de l'informatique sans serveur, voyons ce qu'ils devaient fournir. Les promesses d'une révolution sans serveur étaient nombreuses et - parfois - très ambitieuses.
Pour ceux qui ne connaissent pas le terme, voici une définition rapide. L'informatique sans serveur définit une architecture dans laquelle des applications (ou des 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. Au cours des dernières années, la création de systèmes sans serveur résilients a été une préoccupation majeure des administrateurs système et des entreprises SaaS, car (prétendument) cette architecture offre plusieurs avantages clés par rapport au modèle client / serveur «traditionnel»:
- , , . , .
- ( ). , , . VM, , .
- . , .
En bref, les modèles sans serveur fournissent des solutions flexibles, peu coûteuses et évolutives. C'est incroyable que nous n'ayons pas eu cette idée plus tôt.
Est-ce vraiment une nouvelle idée?
En fait, l'idée n'est pas nouvelle. Le concept de permettre aux utilisateurs de ne payer que pour le temps d'exécution réel du code existe depuis son introduction dans le cadre du Zimki PaaS en 2006, et à peu près au même moment, 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 maintenant appelées «cloud natif», et qui offrent à peu près 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 une connexion entre les deux. FaaS est essentiellement un élément d'une architecture sans serveur orienté calcul, mais il ne représente pas l'ensemble du système.
Alors, de quoi s'agit-il? Eh bien, alors que la vitesse de pénétration d'Internet dans les pays en développement continue de monter en flèche, la demande de ressources informatiques augmente en même temps. Par exemple, de nombreux pays dont le secteur du commerce électronique est en 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 de modèle 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 une valeur significative à certaines entreprises dans certaines circonstances. Mais la principale revendication 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 permettent uniquement aux applications écrites dans certaines langues de s'exécuter. Cela limite considérablement la flexibilité et l'adaptabilité de ces systèmes.
On pense que les plates-formes sans serveur prennent en charge la plupart des principales langues. AWS Lambda et Azure Functions fournissent également un wrapper pour exécuter des applications et des fonctions dans des langues non prises en charge, bien que cela entraîne souvent un coût en termes de performances. Donc, pour la plupart des organisations, cette limitation n'a généralement pas beaucoup d'importance. Mais voici le truc. On suppose que l'un des avantages des modèles sans serveur est que les programmes peu connus et rarement utilisés peuvent être utilisés moins cher car vous ne payez que pour le temps d'exécution. Et les programmes peu connus et rarement utilisés sont souvent écrits dans ... des langages de programmation peu connus et rarement utilisés.
Cela mine l'un des principaux avantages du modèle sans serveur.
Liaison avec le fournisseur
Le deuxième problème avec les plates-formes sans serveur, ou du moins la façon dont elles sont actuellement implémentées, est qu'elles ne se ressemblent généralement pas au niveau opérationnel. Il n'y a pratiquement pas de standardisation en termes de fonctions d'écriture, de déploiement et de gestion. Cela signifie que la migration des fonctionnalités d'une plateforme à une autre prend énormément de temps.
La partie la plus difficile du passage à un modèle sans serveur n'est pas les fonctions de calcul, qui ne sont généralement que des morceaux 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 pas le reste de l'application. C'est exactement le contraire des plates-formes flexibles et économiques 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 elles ne sont pas si nouvelles que ça, comme je l'ai noté ci-dessus, et de nombreuses autres technologies cloud telles que les conteneurs sont déjà devenues beaucoup plus utilisables grâce au développement et à l'adoption généralisée de bonnes normes.
Performance
Les performances de calcul des plates-formes sans serveur sont difficiles à mesurer, en partie parce que les fournisseurs ont tendance à garder les informations privées. La plupart affirment que les fonctionnalités sur les plates-formes distantes sans serveur sont aussi rapides que sur les serveurs internes, à l'exception de quelques problèmes de latence inévitables.
Cependant, certains faits suggèrent le contraire. Les fonctions qui ne se sont pas encore exécutées sur une plate-forme particulière ou qui ne l'ont pas été pendant un certain temps prennent 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 dans le cas des benchmarks - la plupart des fournisseurs ne vous parleront pas du transfert de données.
Il existe, bien sûr, plusieurs façons de contourner ce problème. La première consiste à optimiser les fonctionnalités quel que soit le langage cloud utilisé par votre plate-forme sans serveur, mais cela mine quelque peu l'affirmation selon laquelle ces plates-formes sont «flexibles».
Une autre approche consiste à s'assurer que les programmes essentiels aux performances sont exécutés régulièrement pour les maintenir à jour. Cette deuxième approche, bien sûr, contredit l'idée que les plates-formes sans serveur sont bien sûr 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 démarrages à froid, mais nombre d'entre eux nécessitent une «mise à l'échelle un», ce qui mine la valeur originale de FaaS.
Le problème du démarrage à froid peut être partiellement résolu en exécutant des systèmes sans serveur en interne, mais cela a un coût et reste une option de niche pour les équipes disposant de ressources suffisantes.
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 (généralement) pas exécuter des applications entières.
Plus précisément, ce n'est pas rentable. 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, sans serveur est mieux adapté pour les nouveaux développements. Presque aucune application (architecture) existante ne peut être migré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 pour compléter les serveurs back-end pour les tâches intensives en calcul. 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 du calcul à distance. Cela illustre l'un des défis du passage des microservices aux 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 entreprises. Mais si certaines applications sont sur des serveurs internes et d'autres sur des architectures cloud sans serveur, la gestion atteint un nouveau niveau de complexité.
Vive la révolution?
Malgré toutes ces plaintes, je ne suis pas contre les 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 pour créer des applications sans serveur et voyez comment appliquer au mieux ce modèle.