6 bonnes pratiques pour passer au serverless
La promesse des services cloud dits "sans serveur" (serverless) est alléchante. Ils permettent de déployer et exécuter du code sans avoir à se soucier des serveurs ou machines virtuelles sous-jacentes. Sous le capot, les ressources machines sont automatiquement dimensionnées au regard du trafic. Le code est mis en musique via ce qu'on appelle "des fonctions" en réponse à des événements. Lors de l'appel d'une page web par exemple, elles pourront enclencher les services qui lui sont associés (authentification, interrogation de la base de données, etc.). Si un des composants de l'application tombe, il est immédiatement relancé par une autre fonction. En 2015, Amazon est l'un des tous premiers fournisseurs de cloud à se positionner sur ce terrain avec AWS Lambda. Microsoft lui emboîte le pas en 2016 avec les Azure Functions. En août dernier, c'est au tour de Google d'annoncer ses Google Cloud Functions. Ces solutions de Function as a Service (FaaS) ont également un intérêt économique. Exit l'allocation de machines virtuelles, la facturation se cale sur la ressource IT réellement consommée. Voici comment passer au serverless.
1. Définir les applications éligibles
Malgré sa souplesse, le serverless affiche une limitation de taille. Quel que soit le fournisseur, l'exécution d'une fonction demeure limitée dans le temps. "Elle ne pourra pas excéder 5 minutes chez AWS et 9 minutes chez Google", constate Chrysostom Mobio, consultant cloud chez D2SI, filiale de l'ESN française Devoteam spécialisée sur AWS. Principale conséquence : tous les codes ne sont pas éligibles. Exit celles engendrant des traitements longs tels les calculs distribués, le machine learning ou encore l'encodage vidéo. De même, serverless rime avec stateless (l'inverse de statefull). De par son design, cette technologie ne peut en effet stocker l'état d'une session applicative. "Pour ces types de workload, on pourra faire appel à des services clouds tiers, par exemple une base SQL ou NoSQL", précise Thomas Laporte, consultant Google Cloud Plateform chez GCloud, entité de Devoteam centrée, elle, sur Google Cloud Platform et G Suite.
2. Découper l'application en microservices
Vous l'aurez compris, le serverless implique de découper l'application en petits composants stateless. Des microservices qui viendront se nicher dans les fonctions. "Pour intégrer une telle architecture, un logiciel de gestion des achats par exemple devra être décliné en une série de workloads : gestion des accès, des sessions, enregistrement d'une demande d'achat, vérification des stocks, etc. L'objectif est d'éviter de créer des fonctions trop lourdes qui ne seraient pas éligibles au temps de traitement autorisé par le provider", décrypte Chrysostom Mobio. Et ce sans compter la latence nécessaire au lancement de la fonction. "Plus les librairies logicielles seront légères et le poids du code optimisé, mieux ça vaudra", ajoute Chrysostom Mobio, qui conseille dans cette optique de préférer le langage Python au Java. En matière de langage d'ailleurs, les différentes solutions de cloud serverless ne sont pas toutes logées à la même enseigne. Alors qu'AWS supporte C#, Java, Node.js et Python, les fonctions Google se limitent, elles, aux deux derniers.
3. Gérer la complexité de l'architecture
Du fait de la granularité de leur architecture, les applications serverless pourront très vite se révéler complexes à faire évoluer. Comment s'y retrouver en effet au sein d'une galaxie de nombreux microcomposants ? "Face à ce défi, les bonnes pratiques relatives au développement et à la maintenance du code se révèlent clés, de la documentation logicielle à la gestion de versions en passant par l'automatisation des tests", explique Chrysostom Mobio. Et Thomas Laporte de préciser : "Avec le serverless, on gagne en flexibilité au détriment de la simplicité. La multiplication des petits blocs applicatifs accroissant dans le même temps le risque d'erreur d'exécution et de latence."
4. Tester l'application
Pour éviter toute surprise lors de leur déploiement, les applications serverless impliquent une phase de test des plus rigoureuses. "Il faudra simuler l'exécution des fonctions au plus proche des conditions réelles de production", recommande Chrysostom Mobio. Les offreurs de cloud proposent en général des outils en vue d'orchestrer ce processus. Mais aussi des services d'IAM (Identity & Access Management) pour gérer la sécurité et les droits d'accès à l'environnement.
5. Monitorer en conditions réelles
Dans la même logique, il est important de monitorer l'application une fois celle-ci mise en production. Taux de disponibilité des fonctions, latence, détection de bugs... "La supervision applicative permet de repérer rapidement les erreurs d'exécution et d'éviter qu'elles ne se répercutent sur d'autres fonctions", souligne Thomas Laporte. Et Chrysostom Mobio d'insister : "Ce suivi a par ailleurs pour but de contrôler la consommation du service cloud pour mieux l'optimiser." L'enjeu ? "Trouver le bon équilibre entre la petite taille des fonctions et leur nombre dans l'optique de payer le moins cher possible tout en limitant la complexité globale de l'architecture", résume le consultant. Amazon, Google et Microsoft affichent des solutions taillées pour monitorer les applications serverless mises en œuvre sur leur cloud respectif.
6. Bien choisir son cloud
Tous les fournisseurs de service cloud serverless ne proposent pas les mêmes possibilités. Au regard des besoins, il pourra donc être recommandé de privilégier l'un d'eux. Comme indiqué plus haut, ils ne prennent pas en charge les mêmes langages. Mais ils se différencient également en termes de fonctionnalités (lire l'article : Trois offres cloud "serverless" sur le grill). Alors qu'Amazon se détache par sa maturité et Microsoft par sa richesse en termes d'environnements d'exécution, "Google permet, lui, de déployer des containers Docker via ses Cloud Functions. Il ouvre ainsi la voie à la création d'applications serverless entièrement personnalisées, en termes d'OS, de langages, de dépendances...", insiste Thomas Laporte.