Dans l'air du temps, le serverless tend à vouloir répondre à bien des promesses. Un gain d'argent, de performance, faciliter la maintenance et enfin améliorer la productivité des développements. Mais finalement ces technologies tiennent-elles leurs promesses ? Est-ce que je dois me tourner vers du serverless ?

C'est quoi ?

Si l'on traduit littéralement le mot "serverless" cela nous donne : "sans serveur".

Mais arrêtons nous ici, l'informatique a encore besoin de ses serveurs ( et potentiellement des OPS qui vont avec, ouf ! ) et la traduction littérale n'apporte rien ici.

En réalité la seule question posée par cette notion est "Qui est propriétaire des serveurs ?" : l'utilisateur final ( ou clients finaux ) n'est en réalité plus propriétaire de ses serveurs. Il loue uniquement du temps d'utilisation auprès de fournisseurs "Cloud" ( AWS, Google et autes qui sont appelés dans ce cas des providers ), il est donc "serverless". Il n'est donc pas question ici de faire de l'informatique sans serveur !!

Prenons un exemple concret : je souhaite réaliser un script python qui va transformer des images ( png/jpeg ) vers du pdf. Mais je ne souhaite pas m'occuper de l'hébergement.

Et encore moins me soucier du "comment le rendre accessible".

Alors je peux dans ce cas, louer l'utilisation d'un serveur chez un provider pour éxecuter uniquement ce script. Bien évidemment en fonction de mes besoins ( en l'appelant via une URL HTTP par exemple ), mon script va lui même me fournir un retour au format HTTP.

C'est pratique et ça me permet de ne pas louer ou acheter un serveur physique pour réaliser cette tâche, ni me soucier de l'éventuel mise en place. On parle ici de FaaS ( Function-as-a-Service ).

De plus, je ne serai facturé qu'à la consommation et à l'exécution de ma requête et non plus sur une taille d'instance de serveur. Peu importe l'importance du traitement en terme de CPU ou RAM ! ( attention tout de même, chaque provider pose des limites que je ne vais pas aborder ici )

En réalité le développement des applications s'est vu complètement redéfini au cours des 10 dernières années. D'application pensée d'un seul bloc (monolithique), nous sommes arrivés à des applications qui se sont vues découpées en multiples blocs de code réalisant chacun une action bien spécifique. Parfois sous forme de micro-services.

Ce découpage permet notament une meilleure utilisation du principe de conteneurisation ( pour en apprendre plus sur la conteneurisation : Docker c'est quoi ) et donc du "cloud" (qu'il soit privé ou public).

De plus les techniques de conteneurisation ont permis aux développeurs de se passer d'une problèmatique jusque là importante : l'infrastructure. Enfin, c'est facilement récupérable et ce dans n'importe quel environnement : la fameuse interopérabilité.

Bien sûr ces techniques ont forcément des gains et des limites, je ne vais pas sortir une liste exhaustive mais voici les principaux.

Gain

  • Coût opérationnel réduit de plusieurs éléments :

    • Le coût d’infrastructure, pas d'achat de matériel mais également dans certains cas les licences ou le support logiciel.
    • Le coût en effectif : moins d'opérations = moins de personnels dans l'équipe ( Attention, cette vision est clairement à nuancer devant la compléxité de mettre en oeuvre une telle infrastructure. C'est surtout l'occasion de revoir les places dans une équipe et offrir des évolutions à certains postes : SysAdmin vers du DevOps par exemple )

  • Coût de l'auto-scaling ( mise à l'échelle de l'infrastructure ) :

    • Plus besoin de sur-dimensionné son infrastructure,
    • En cas de pique de trafic, le provider founira plus de ressources.

Limites

  • Dépendance aux cloud providers :

    • Si il est en panne, vous êtes en panne.
    • Si les règles d'utilisation changent, vous devez changer.
    • Si les prix augmentent, ...

Bref vous êtes lié à votre choix de service provider.

  • Offre inadaptée. Parfois l'offre ne s'adaptera pas à votre besoin :

    • Temps de traitement de votre fonction trop longue par exemple.
    • Latence lors de l'instanciation ( 10s ça peut être long dans certains cas ... )

  • Maintenance et supervision :

    • Comment je sais que mon script FaaS va correctement fonctionner ? Ou je peux trouver les logs en cas de besoin ?

  • ⚠️Vos données ...

    • À qui je donne mes données dans le cloud??

Le serverless arrive et arrivera même chez vous ( tout comme l'IPv6 ), maintenant il y a plusieurs façon de l'aborder.

Vous n'êtes pas obligé de passer par un cloud publique pour le faire, et vous n'êtes pas obligé non plus d'envisager l'embauche d'une équipe complète pour gérer votre cloud privé.

Posez-vous simplement les bonnes questions : Est-ce que cela est vital pour mon activité ? Est-ce que je peux envisager d'utiliser du serverless dans mon prochain projet ?

Il existe également des projets open-source qui vont apporter ces solutions à tous, par exemple OpenFaaS. Nous essayerons également de découvrir ensemble cette solution !

En résumé, il faut mettre en relation vos besoins avec la technologie. Je pense encore une fois que le plus important, c'est de toujours suive ce mantra : Think by yourself, dont be a sheep.

rickandmorty