Simple ? Explications
Les principaux enjeux ont déjà été mentionnés dans les précédents chapitres (dont celui sur la portabilité d'un produit).
Nous préconisons de choisir chez un hébergeur ce qui pourrait se référer au "serverless" pour votre applicatif, ce afin de juste avoir à jouer sur le nombre d'instances ou les ressources disponibles pour répondre à votre besoin. Nous parlons ici de serverless sur des "images finales" dont la technologie est open source (comme Docker ou Buildpack), et non pas de FaaS (functions as a service).
Les FaaS répondent à un besoin sommaire (comme un script), mais rarement au besoin d'un produit complet (sachant qu'un ensemble de "functions" indépendantes poserait un problème de synchronisation des versions du runtime comme mentionné ici).
Il nous semble par exemple démesuré de gérer la complexité de ressources sur un cluster Kubernetes pour gérer un produit. Bien évidemment certaines entités ont déjà de tels clusters en place et on vous redirige vers la validité de ce guide pour ne pas être en porte-à-faux vis-à-vis de votre entité. Gardez juste en tête que le coût opérationnel (temps / argent) pour maintenir de tels outils est bien supérieur au fait de payer un hébergeur tiers. D'ailleurs ceux qui sont déjà passés par-là ont peut-être remarqué que finalement on refait le travail d'un hébergeur traditionnel, sauf que l'on a pas le budget pour (ni la légitimité pour 😊), et on arrive difficilement à un résultat qualitatif (autonomie des équipes, documentation, outils de monitoring…).