j’ai écris il y a quelques temps un article appelé l’important n’est pas la technologie mais la plateforme qui est en lien avec le sujet de cet article. J’ai également eu l’occasion de donner un talk à AlpesCraft nommé rendez vos développeurs autonomes sur la production (slides ici), où l’explique pourquoi il est important aujourd’hui de laisser les équipes de développement gérer eux même, dans un certain périmètre, leurs services en production.

Je pense en effet que, comme le PaaS nous le promet, il est important que les développeurs puissent se concentrent sur le développement (et donc sur créer de la valeur), et qu’il faut donc leur fournir de l’outillage leur permettant de déployer (très souvent) et gérer (au sens large: rollbacks, logs et métriques, service discovery…​) leurs applications en production.

A première vue, les PaaS répondent à ce besoin. J’ai d’ailleurs passer de longues journées récemment à tester les deux principaux PaaS Français pour un besoin de ce type, et il existe également bien sûr des PaaS d’autres pays fournissant en théorie ces fonctionnalités.
En pratique, la réalité est tout autre.

Les PaaS nous fournissent une abstraction de l’infrastructure. C’est, comme dit précédemment, exactement ce que l’on veut. Sauf que les fonctionnalités offertes par cette abstraction laisse souvent à désirer.
Les PaaS s’adressent principalement à un public de développeur, qui ont au final peu de connaissances en infrastructure ou en gestion de production. Beaucoup d’utilisateurs de PaaS ne sont donc pas vraiment en capacité de juger l’abstraction proposée par le PaaS. Voici quelques exemples sur ce que je rencontre régulièrement sur ce type de plateformes.

Nous sommes en 2022 et il est souvent difficile, voir impossible, de faire communiquer plusieurs applications de manière sécurisée. Les outils type base de données sont souvent exposées sur internet, il n’est pas possible de mettre en place des règles de firewalling fines. Les applications sont très souvent contraintes sur ce qu’elles peuvent exposer comme type de services (par exemple seulement de l’HTTP, sur un seul port).

La partie précédente sur le réseau montre bien que n’importe quelle entreprise ayant un minimum d’exigence de sécurité ne peut pas utiliser ce type de fournisseur. L’absence de gestionnaire de secrets, qui sont souvent stockés et passés comme simple variables d’environnements (pratique qui est souvent la cause de leak de secrets d’ailleurs) est également problématique. Les utilisateurs exigeants voulant par exemple faire du mTLS entre services seront également déçus.

Les PaaS se chargent de déployer chaque nouvelle version du logiciel déployé. De manière assez surprenante, il est souvent impossible de configurer nous même le health check à exécuter sur l’application. C’est pourtant un aspect essentiel sur la gestion d’un déploiement, notamment pour pouvoir faire des rolling updates de type "graceful", sans aucune pertes de requêtes et en drainant proprement les instances de l’application à éteindre.
Ce n’est d’ailleurs pas pour rien que Kubernetes possède différents types de health checks (startupProbe, livenessProbe et readinessProbe) ou des options de type terminationGracePeriodSeconds, pour contrôler finement comment l’application va réagir en cas d’arrêt ou au démarrage. Rien de pire que de perdre du trafic ou perdre des tâches en cours d’exécution à chaque déploiement, ce qui sera le cas sans la gestion de ces paramètres.

Cette petite liste n’est bien sûr pas exhaustive. J’aurai pû également parler de l’outillage qui laisse souvent à désirer. Un novice ne verra pas ce type de problèmes. Ils sautent pourtant aux yeux de n’importe qui ayant une certaine expérience dans la gestion d’infrastructures.

J’ai écris il y a quelques temps un article nommé développement d’applications, conteneurs, et plateforme d’exécution. Presque 2 ans après, je pense toujours la même chose: une application bien conçue doit pouvoir tourner sur différents types de plateformes (bare metal, machines virtuelles, environnement conteneurisés…​). Si votre application expose ses métriques au format Prometheus sur /metrics, qu’elle génère des logs propres en JSON, qu’elle se configure simplement (via un simple fichier de configuration par exemple), expose un endpoint type /healthz Il n’y a aucune raison que vous ayez à réécrire votre application pour tourner sur un runtime particulier.

Cela n’est pas vrai sur le PaaS. Le fait dans certains PaaS de ne supporter que HTTP, sur un seul port, exclut un grande nombre d’applications. D’autres ne supportent pas le passage de fichiers de configuration, mais ne supportent que les variables d’environnement, ce qui exclut le déploiement d’une majorité des logiciels. On va vous dire "ah non, nous on ne supporte pas les métriques au format Prometheus, il faut utiliser un autre protocole". Bref, vous allez lier votre application à la façon dont fonctionne votre provider, ce qui est pour moi un problème.

Les PaaS essayent de fournir une expérience tout en un aux développeurs: ils font un commit, le code part en production. C’est donc le PaaS qui se charger de récupérer les dernières modifications (via Git), de construire l’artefact à déployer, et de le lancer.

Je n’ai jamais compris cette approche. J’ai toujours personnellement travaillé en décorrélant la partie CI (lancement des tests, construction et stockage de l’artefact à déployer) de la partie déploiement. Je ne veux pas avoir à passer par une phase de build obligatoire avant de pouvoir déployer, je veux pouvoir le faire de mon côté, avec mes propres outils, fournisseurs d’outils de CI ou de gestion de dépendances et artefacts (Artifactory, Docker Hub…​).
Avoir autant de couplage est problématique et je ne considère pas cela une bonne pratique

Le PaaS, s’occupant de tout pour vous, est probablement le type de cloud créant le plus de vendor lock-in. Vous avez même souvent dû, comme dit précédemment, adapter votre application pour tourner dessus !
Cela n’est pas forcément un problème (le lock-in étant un choix qui peut se justifier si il permet de travailler efficacement), mais c’est à garder en tête.

Un autre problème du PaaS est l’offre restreinte de produits disponibles. Quelques bases de données et bus de messages, et c’est tout.

Il est très courant d’avoir besoin de plus. C’est là que le bon vieux IaaS (Infrastructure as a Service) rentre en action. Il y a d’ailleurs quelque chose d’intéressant à énoncer sur le sujet: il est possible de construire sur un IaaS (ou meme dans son propre datacenter) n’importe quoi, PaaS inclus. L’inverse n’est bien sûr pas vrai.
Votre machine virtuelle avec ipsec dessus pour discuter avec un fournisseur externe, cette petite base de données non disponibles as a service mais que vous voulez utiliser, ce client qui veut absolument pouvoir faire du sftp…​ Tout cela est possible si votre provider cloud fournit également de l’IaaS.

Et croyez moi, ces cas non supportés par un PaaS arrivent très vite. C’est en partie d’ailleurs pour cela que beaucoup d’entreprises quittent rapidement le PaaS pour aller chez des acteurs plus gros type AWS (qui a l’avantage de fournir aussi des produits types PaaS), par ne plus être limité par ce que le PaaS propose.

Mais donc, le PaaS actuel est-il voué à disparaître ? Non. Comme aujourd’hui, certaines personnes avec de petits besoins vont y trouver leur compte.

Ce que je trouve beaucoup plus intéressants, c’est l’apparition de PaaS spécialisés qui viennent en complément des gros cloud providers. Je pense notamment à Netlify (où tourne ce blog et un certain nombre de sites web que je maintiens), qui pour moi est un des meilleur produit dans sa catégorie. Héberger des sites statiques chez Netlify peut être complètement décorrélé de l’hébergement de l’infrastructure principale de votre entreprise chez AWS par exemple.
Cloudflare, et sa partie worker, est également un bon exemple. C’est un produit qui viendra en addition du reste de votre infrastructure, avec peu de couplage.

Les fournisseurs IaaS traditinnels fournissent également de plus en plus de services haut niveau. Comme dit précédemment, cela permet à terme de faire cohabiter les deux mondes (IaaS et PaaS) sur le même cloud provider, et avec une très bonne intégration entre les produits.

Ce n’est pas un hasard si la majorité des entreprises tech aujourd’hui construisent leurs propres PaaS internes en utilisant Kubernetes, en s’appuyant bien sûr sur des offres Kubernetes as a service fournies par des cloud provider.
Kubernetes peut sembler complexe, mais c’est aussi parce qu’il vous expose toutes les options pour faire tourner vos applications correctement (notamment les points que je citais en début d’article, mais aussi beaucoup d’autres), et sans a priori sur comment votre application va se comporter. Il est beaucoup plus simple de porter une application "legacy" sur Kubernetes que sur un PaaS traditionnel.
Je pense que l’on verra de plus en plus des offres PaaS basées sur l’API Kubernetes, mais avec les parties réseau, observability, load balancing et ingress…​ gérées par le cloud provider et avec une facturation au pod (et donc, sans notion de noeuds worker pour le client). C’est déjà des choses qui commencent à apparaître et qui je pense vont peu à peu se démocratiser

Il est possible que certains fournisseurs PaaS arrivent à rebondir en améliorant leurs offres et en proposant en complément des produits orientés IaaS pour donner plus de flexibilité aux clients. Mais il semblerait qu’aujourd’hui cela soit plus simple pour un IaaS de sortir peu à peu des produits PaaS que l’inverse.

Tout est dans le titre de l’article. Je pense que le PaaS traditionnel ne sera qu’une niche sur le marché du cloud, et qu’à l’avenir on se tournera de plus en plus vers des PaaS spécialisés, des acteurs IaaS du cloud qui proposent des outils PaaS/FaaS totalement intégrés à leurs écosystèmes (ce que font déjà les gros acteurs), et des PaaS utilisant Kubernetes avec plus ou moins de fonctionnalités gérées par le cloud provider (et donc avec plus ou moins de choses à gérer en interne).

On verra dans quelques années si cet article était exact ou non. C’est tout l’intérêt d’un blog d’ailleurs: se relire quelques années après publication, et là deux réactions sont généralement possibles: un sourire satisfait ou un gros /facepalm. Qui vivra verra.