Un blog serverless

Bienvenue sur ce blog serverless fr ! Tout d’abord un petit post pour présenter rapidement le serverless et donner le ton de ce blog.

Pourquoi useless sysadmin

Je suis convaincu que le métier de sysadmin est en train de disparaitre au profit du serverless, la transition sera longue et aura le mérite de combler la pénurie actuelle de profil compétents. Cette transition s’annonce passionnante et doit, je pense, donner un objectif aux sysadmins actuels : devenir inutile !

Cela vous donnera le temps de vous consacrer à d’autre tâches comme la veille technique autour des services serverless et surtout guider votre entourage dans cette transition que vous serez les mieux placer pour accompagner et motiver.

Qu’est ce que le serverless ?

Comme son nom l’indique, un service serverless ne s’appuie sur aucun serveur mais il faut nuancer ce propos car vous vous doutez bien qu’il y a bien quelques serveurs quelque part qui font tourner le service. L’idée c’est d’utiliser uniquement des services externe (tarifés à l’utilisation) et aucun serveur que nous aurions à administrer nous même.

Comment ce blog est serverless ?

La première étape consiste à avoir un blog statique, pour cela j’utilise Hexo, un projet NodeJS de génération de blog.
Ensuite je stocke les fichiers statiques de ce dernier sur un bucket (sorte de répertoire) S3, et j’utilise CloudFront pour le publier et faire l’offloading SSL. Pour la partie hébergement DNS j’utilise le service route53 d’AWS.

Deux gros avantages

Le coût

En cas d’absence de trafic sur votre service vous n’aurez aucun coût car vous êtes facturé à l’utilisation du service. Très rassurant pour un petit blog ou un site qui de toute façon ne génèrera que très peu de trafic, par contre si d’aventure votre site rencontre le succès alors il va falloir surveiller attentivement le coût de votre hébergement.

La haute disponibilité

On se décharge de toutes les contraintes de haute disponibilité sur les services, ce n’est plus notre affaire on va enfin pouvoir dormir tranquille !

La scalabilité

Pareil que pour la haute disponibilité, si notre site ou service rencontre d’un coup beaucoup de succès nous n’auront rien à faire, le serverless tiendra la charge. Par contre attention au porte monnaie 😉

Les moins

Nécessité d’adapter ses méthode de développement

Si vous ne pouvez pas vous appuyer sur des micro services externes et que vous avez besoin d’apporter des fonctionnalitées dynamique qui vous sont propre vous aller devoir vous appuyer sur Lambda, le projet d’exécution de fonction d’Amazon.

Même si Lambda est disponible dans de nombreux langages vous aurez rapidement besoin d’un langage évenementiel et donc de NodeJS. De plus de nombreuse limites en terme de taille et de durée d’exécution vont vous forcer à multiplier les fonctions et vous organiser en micro service.

Disparition du métier de sysadmin

Beaucoup de missions habituellement affecté aux sysadmin vont certainement disparaitre avec le développement de l’autonomie du développeur/webmaster. La gestion des problématiques en Haute dispo et de tenu de charge pourra être faite simplement depuis l’interface. Attention toutesfois de nombreuses actions et décision d’architecture auront toujours besoin d’un sysadmin qui deviendra au fil du temps plus un architecte du déploiement.

Dépendance aux fournisseur

En toute logique avec l’utilisation maximale de service externe vous augmentez votre dépendance par rapport à ces fournisseurs. Vous êtes donc vulnérable à une modification technique ou tarifaire d’un service pas suffisament concurentiel.

On ne peut pas tout rendre serverless

L’hébergement traditionnel garde pour l’instant son utilité, on ne peut pas par exemple héberger un blog wordpress en full serverless car vous aurez besoin de composants (exécution php, gestion de sessions, base de donnée).

Prenons pour exemple l’hébergement de la base de donnée, si vous pouvez vous passer de gérer vous même votre serveur en utilisant par exemple un serveur MySQL managé vous serez obligé de payer un coût récurrent correspondant à votre serveur.

L’offre MySql serverless d’Aurora aws ne fait pas exception avec un coût horaire à payer : même pour un site avec une très faible audience et quelques dizaine de requêtes par jour vous aurez rapidement une facturation importante de l’ordre de deux dollars par jours. Notons tout de même qu’il fournit un système de pause, avec une suspension du service MySQL suite à une période d’inactivité. Belle tentative, mais il faut 25s pour relancer le service quand une requête arrive, trop long pour l’affichage d’un site web donc pas vraiment utilisable !

L’arrivé des fonctions Lambda AWS (on y reviendra dans un prochain post) met un gros coup de pied dans la fourmilière mais est loin de proposer autant d’applications que l’hébergement traditionnel et pour l’instant reste réservé aux développeurs aventureux.

Bel avenir

Les perspectives d’économies, de simplicité et de haute disponibilité sont des atouts majeurs qui propulse le serverless sur le devant de la scène et rendront d’ici peu le dernier buzz word “container” obsolète.

En attendant je vais continuer mon exploration du serverless et essayer de faire quelques tutoriels sur le sujet.

Liens utiles

6 things I’ve learned in my first 6 months using serverless

Serverless : les pour et les contre