Devops for Growth

Au niveau de la conception tout d’abord, l’approche microservice semble naturelle aujourd’hui. Les Fonctions as a Service incitent à partitionner l’application en une multitude de fonctions qui se coordonnent entre elles. Ce découpage favorise la modularité et le choix des technologies les plus appropriées. Mais le mieux est souvent l’ennemi du bien. Prenons l’exemple d’une modularité à l’extrême avec une fonction par ressource et par verbe HTTP. Une petite application avec 6 ressources et n’utilisant que 2 verbes par ressource nécessitera pas moins de 12 fonctions. Cela va nécessiter 12 processus de builds indépendants, 12 configurations d’Infra as Code donc beaucoup de complexité et de temps de déploiement. N’y a-t-il pas une meilleure façon de faire ?

La programmation fonctionnelle et la programmation évènementielle mises en avant par les plateformes de Functions As a Service répondent très bien à l’enjeu de l’informatique pervasive. À l’inverse, elles présentent un challenge très important pour réaliser des applications plus classiques. En effet, le temps de démarrage d’une Fonction as a Service peut atteindre quelques secondes lors du premier appel.

Certaines propositions émergent comme l’architecture en service block. Cette architecture ré-introduit une instance de type microservice pour gérer l’interaction avec l’utilisateur (ce que nous avons nommé informatique interactive). Là encore, n’y a-t-il pas une meilleure façon de faire ?

Le debuggage ensuite. Lorsqu’on développe du code destiné à être déployé sur des Plateformes as a Service, son exécution est dépendante de cette plateforme.

Celle-ci devra à la fois faire office d’environnement de développement, de qualification et de production. Gérer de multiples environnements dans un même service est complexe si le service n’offre pas de support aux environnements multiples.

La boucle de feedback est longue du fait du temps de déploiement de l’application.

La plateforme fournit des logs à l’exécution, mais ceux-ci peuvent s’avérer trop limités dans un besoin de développement. L’usage d’un outil de debuggage devient indispensable. Certaines plateformes permettent d’exécuter leur runtime dans un conteneur docker sur le poste développeur mais au prix de certaines limitations quant aux services managés testés.

A l’inverse des frameworks applicatifs permettent de se rendre indépendant de la plateforme. Quelle solution doit-on privilégier ?

L’intégration des différents services joue un rôle crucial en miroir des choix de conception. Faut-il privilégier des fonctions extrêmement simples en confiant beaucoup de responsabilités à des plateformes d’intégration : une API Gateway ou une plateforme de type Kubernetes (si on utilise un FaaS comme RIFF) ? En d’autres termes, faut-il privilégier une approche très orientée Service Mesh ou redonner un peu de responsabilité à l’application ?

Dans une plateforme de Function et de Backend as a Service, l’infrastructure est prise en charge par la plateforme. Est-ce que l’Infrastructure As Code ne devient pas superflue ? Nos premières expériences montrent qu’avec l’augmentation du nombre de fonctions, l’organisation du déploiement devient au contraire un enjeu majeur pour gérer la complexité liée aux grands nombres de services.

L’observabilité enfin est un enjeu majeur, car les infrastructures sont on ne peut plus volatiles. Le meilleur moyen pour diagnostiquer un problème sur une application Serverless repose sur l’observabilité. Or, il n’y a plus aucun serveur sur lequel stocker ses logs ni même se connecter. Tout est à réinventer.

Chacune de ces questions pourrait nécessiter un article à part entière.