Avez-vous entendu parler de l’informatique sans serveur ? Devinez quoi, ce n’est pas du tout sans serveur. Il automatise simplement l’allocation des serveurs principaux dont vous aurez besoin pour effectuer une tâche particulière. Aujourd’hui, nous avons des dizaines de types de systèmes sans serveur, des bases de données aux conteneurs en passant par les systèmes de développement plus traditionnels. Ils tiennent tous la même promesse : fournir une mise à l’échelle verticale et horizontale automatiquement sans avoir à configurer les serveurs à l’avance.
Cela signifie que les développeurs n’ont pas à deviner le nombre de serveurs de stockage et de calcul à lancer avant l’exécution des applications. Les systèmes sans serveur prennent ces décisions pour vous, en allouant les ressources dont vous avez besoin pendant l’exécution et en les désallouant lorsque le besoin n’est plus là.
L’automatisation est vraiment la valeur clé. Nous n’avons plus à essayer de déterminer le nombre de ressources dont nous aurons besoin. Choisir trop de ressources (dont la plupart nous oublions de fermer) entraîne une énorme facture cloud à la fin du mois. Choisissez trop peu de ressources et nous observons l’échec de nos applications peu de temps après le lancement.
J’ai personnellement laissé des ressources fonctionner et j’ai toujours regretté le fait que les fournisseurs de cloud m’obligent, en tant qu’humain, à choisir les ressources dont j’avais besoin. Il ne s’agit pas de savoir si vous vous trompez, mais de savoir à quel point vous vous trompez.
Ainsi, j’aime le serverless en tant que concept. À moins qu’un client ne sache bien quelles ressources seront nécessaires, il est plus sûr d’opter pour de nouvelles applications cloud natives que d’essayer de deviner la capacité nécessaire. De plus, vous avez la possibilité d’augmenter et de modifier la capacité en continu. C’est là que réside la valeur du sans serveur, à mon avis.
Le contre-argument est que le sans serveur est plus cher que les ressources auto-allouées avant l’exécution. En effet. Cependant, cela suppose que vous choisirez correctement une configuration optimale qui démarre et s’arrête au bon moment et dans le bon ordre. Certains peuvent y parvenir, mais la plupart ne le peuvent pas.
En outre, le sans serveur présente plusieurs inconvénients que la plupart ne comprennent pas tant qu’ils ne l’ont pas utilisé. Il est « natif du cloud » ou spécifique à un seul fournisseur de cloud public, ce qui signifie que la portabilité facile n’est pas une caractéristique du sans serveur sur aucun fournisseur de cloud public. Il existe peu ou pas d’outils de gestion et de surveillance pour les systèmes sans serveur natifs au-delà de ceux fournis par le fournisseur de cloud public qui le vend.
Le sans serveur est l’une de ces technologies qui a clairement des compromis, mais avec sa maturation au cours des sept dernières années, nous voyons un chemin de valeur clair pour le sans serveur pour de nombreuses charges de travail réseau nouvelles et natives du cloud. Cela dit, cela dépend aussi beaucoup de ce que vous construisez et dans quel but puisque vous échangez la portabilité contre l’automatisation de l’allocation des ressources et avez moins de choses à vous soucier.
Dans la plupart des utilisations que je vois, le sans serveur est logique. Mais c’est toujours du cas par cas.
Toute l’actualité en temps réel, est sur L’Entrepreneur
