Cet article fait partie de notre guide: Serverless : bien comprendre cette architecture applicative

Serverless : ce qu'il faut considérer avant de se lancer

Le Serverless a certes attiré l'attention de nombreux développeurs. Mais il faut rester particulièrement attentif aux problèmes de portabilité.

L'informatique Serverless a été au centre de nombreux discours l'année dernière. Amazon a bien sûr pris la tête du peloton avec ses fonctions Lambda. Et les entreprises, elles, semblent suivre le mouvement.  Cependant, le chemin pourrait bien être chaotique pour celles qui veulent utiliser le Serverless en environnement multi-Cloud, pensent certains experts. 

« Les fournisseurs de Cloud ne voient probablement pas leur intérêt à créer des passerelles pour faciliter l’accès au Serverless », constate Rich Sharples, directeur principal des produits chez Red Hat. « Mais à terme, cela sera bénéfique aux utilisateurs qui ont adopté le multi-Cloud ou ceux qui souhaitent être agnostiques en termes de Cloud. Les architectes d'entreprise doivent évaluer les risques entre être verrouillé sur une plateforme Cloud, et bénéficier de services, comme un monitoring optimisé, ajoute le responsable.

Les difficultés du Serverless 

Actuellement, les fournisseurs de Cloud proposent de nouvelles plateformes Serverless, tout en promettant de délivrer les développeurs de la gestion de l'infrastructure. Cependant, cela peut conduire au fameux verrou-vendeur. Les développeurs utilisent en effet les services spécifiques à chaque plateforme, comme l'orchestration des fonctions par exemple. 

Pour résoudre ce problème, la Cloud Native Computing Foundation (CNCF) travaille à améliorer la portabilité avec des spécifications, comme Kubeless et OpenWhisk. Les développeurs peuvent utiliser les bibliothèques d’API et des frameworks Serverless pour créer des applications portables entre Clouds, a déclaré Michael Coté, directeur du marketing technique chez Pivotal. Il s'attend à l'émergence de nombreux frameworks pour .Net, Java, Ruby, Python et PHP. Il s'attend également à une bataille entre développeurs pour connaître quel sera le meilleur des langages pour le Serverless.

A architecture Serverless, services réduits 

La croissance des offres, et les gains en matière de réactivité, devrait également permettre aux entreprises de développer, de tester et de déployer des services plus réduits, s’accordent à dire certains experts. Les entreprises auront ainsi la possibilité d'assembler et de désassembler les applications d'une manière qui n'était pas possible jusqu’alors. 

Ces modèles Serverless fonctionnent pour les applications simples et qui ne nécessitent pas d’état, commente Ravi Mayuram, CTO chez Couchbase (base NoSQL). Ces services stateless fonctionneront de pair avec des bases de données JSON et les applications. Si une interface JSON est présente dans la base, les entreprises auront d’importantes possibilités d’évolution.

Identifier le bon cas d’usage

Malgré le battage médiatique, le Serverless en est encore à ses débuts. Amazon a certes pris les devants avec son offre Lambda, et ce, malgré des SLA limités. Les entreprises devront donc évaluer la performance de ces nouvelles applications, et identifier les bons cas d’usage avant de s'engager, affirment les experts.

Pour adopter les frameworks Serverless, il faut une bonne dose d'optimisme, de foi et d'indifférence, pense Owen Garrett, responsable des produits chez Nginx. Optimisme, car les développeurs doivent prier qu'une fonction se déclenche dans le bon timing ; foi car, si cette fonction ne se déclenche pas une fois, il se peut qu’elle s’exécute une autre fois ; et l'indifférence quant à savoir si elle fonctionne réellement.

Il sera également plus difficile de débuguer et de récupérer des informations sur les pannes car les applications Serverless ne stockent pas d'état, disent les experts. Les développeurs auront donc besoin de nouveaux outils. Les architectes d'entreprise, de leur côté, auront une responsabilité :  créer des schémas directeurs et de la documentation pour les tests et les déploiements, au risque d’être confrontés à la fragmentation de l’architecture.

Pour approfondir sur Architectures logicielles (SOA)

Close