Le serverless, je ne connais pas du tout. L’idée est de faire une série d’articles découvertes sur cette architecture. L’idée est d’aller jusqu’à la création d’une petite application.
Depuis deux ans on parle de plus en plus de serverless mais il n’est pas toujours simple de voir exactement de ce que cela implique pour une application d’être serverless. Autre point, est-ce qu’être serverless implique qu’il n’y ait pas de serveur du tout ?
Les principes du serverless
Le serverless est une nouvelle façon d’héberger ses applications. Avec docker et des orchestrateurs comme kubernetes il est possible de faire de l’auto-scalling pour adapter le nombre d’instances d’une application en fonction de l’utilisation de l’application. M6 Web a d’ailleurs fait un retour d’expérience d’auto-scalling via la mise en place de kubernates.
Le serverless est l’étape suivante de l’auto-scalling tout en apportant une approche micro-service. Quand personne ne va utiliser une application, il n’y aura aucune instance qui tourne (selon les solutions). Et c’est seulement au premier hit que l’application sera bootée. En fonction du nombre d’appels, il y aura plus ou moins d’instances qui tourneront en même temps. L’application est donc fortement liée au backend utilisé.
Cette approche permet, selon la solution choisie, de limiter les coûts d’hébergement car les providers (Amazon, Google, Microsoft,…) facturent l’hébergement à la seconde, ou même au centième de seconde d’exécution. Si personne n’utilise l’application, les coûts d’infrastructure seront quasiment nuls.
Et c’est bien là, la force de cette approche. Quand on loue des serveurs à l’année on est obligé de payer pour un nombre de serveurs permettant d’absorber les pics maximum de charge. Le reste du temps les serveurs sont sous-exploités.
La rapidité
Le serverless n’est possible que si on est capable de démarrer un service rapidement. Si l’application met 30 secondes à démarrer, il faudra toujours conserver au moins une instance de disponible. A ce moment là on en revient à une solution d’autoscalling classique.
La fiabilité
La mise en place d’une architecture serverless déporte une partie de la complexité de l’application sur l’infrastructure qui va orchestrer nos fonctions. Il est donc primordial qu’elle soit fiable et résiliante. Il est donc préférable, pour une application de production d’utiliser une solution hautement disponible (HA).
La scallabilité
Par nature une architecture serverless est scallable car elle va devoir instancier à la demande des applications. Mais pour que ce soit possible il faut que l’infrastructure l’autorise (allocation/ libération de ressources à la volée).
Le nouveau paradigme
Cette infrastructure impose que chaque fonction soit stateless, mais vous avez la possibilité d’interagir avec d’autres services comme des bases de données ou des APIs.
Le développeur est pleinement conscient du fonctionnement de l’infrastructure. Comme on l’a vu précédemment, la frontière est mince entre l’application et la solution d’hébergement.
Cette façon de travailler permet, en théorie, de réduire le temps de déploiement d’une fonctionnalité car la complexité de chaque fonction est plus faible que celle d’une application monolithe. Néanmoins le risque est d’avoir autant de façons de faire que de fonctions hébergées. Comme chaque développeur va pouvoir travailler « dans son coin » en faisant fi de l’existant, les dérives et les mauvaises pratiques sont vites arrivées. Il y a, à mon avis, un besoin de revue de code et de tests encore plus important sur ce type d’architecture.
Le dernier point et que l’on peut avoir un langage commun sur les problèmes de performance avec la hiérarchie. Comme chaque seconde de traitement augmente la facture, il est plus simple de mettre en avant des projets techniques d’optimisation. Un temps de traitement divisé par deux c’est une fonctionnalité qui coûte deux fois moins cher. Ce n’est pas réellement le cas sur une application classique.
En conclusion, le serverless est une nouvelle approche sur la façon de concevoir une application en poussant au maximum les approches devops et micro-services afin de concevoir une application hautement scallable tout en maîtrisant les coûts.
Laisser un commentaire