skvoor - Fotolia
Serverless : les développeurs doivent rester prudents
Le serverless a ses avantages, mais si les outils ne fonctionnent pas comme prévu et si la courbe d'apprentissage s'avère trop raide, la mécanique pourrait se gripper.
Le serverless est aujourd’hui très en vogue. Les développeurs s'enthousiasment pour les avantages d’une telle architecture et, en particulier, sont séduits par la possibilité de déplacer leurs applications Java, qu’elles soient installées sur des serveurs traditionnels ou dans des containers, vers des plateformes plus éphémères, comme AWS Lambda, Azure Functions ou Google Cloud Functions.
Une application serverless bien conçue comprend souvent un mélange d'éléments de type backend-as-a-service (BaaS) et function-as-a-service (FaaS). Le FaaS, comme AWS Lambda, correspond souvent à ce que les développeurs considèrent comme étant le serverless. Toutefois, il ne faut pas oublier le BaaS qui permet d’apporter une authentification plus transparente et un accès aux données. Une fois associés, Faas et Baas facilitent le développement d'applications et provisionnent automatiquement des ressources de calcul sous la forme de code.
Anticiper les éventuels problèmes
Les aspects financier et évolutivité font partie des avantages du serverless. Mais il est aussi important de reconnaître que cette architecture n’en est qu’à ses débuts et les utilisateurs vont parfois se confronter à de sérieux problèmes, avertit Nathaniel Schutta, architecte logiciel chez Pivotal.
Il s'est dit préoccupé lorsqu'un de ses développeurs est venu lui parler d'un projet de refonte complète d’une application en serverless. « Le problème est le suivant : nous adoptons une technologie parce qu’elle est à la mode et nous finissons par le regretter à un moment donné », lance-t-il.
Un problème justement : ces fonctions serverless ne sont adaptées qu’à peu de cas d’usage. Si elles peuvent en effet surmonter certaines contraintes du développement traditionnel, elles peuvent aussi en ajouter de nouvelles que les développeurs ne découvrent qu’en avançant. « Je suis toujours étonné de voir qu’une technologie est mise en place alors qu’elle ne convient pas », ajoute encore le spécialiste.
Le problème tient en partie au fait que de nombreux outils serverless ne fonctionnent pas comme prévu. Nathaniel Schutta cite l’exemple d’un développeur qui a peiné à gérer en back-end l’orchestration de fonctions sur AWS. Après plusieurs mois d’essais d’AWS CloudFormation, ce développeur est finalement passé à Terraform. En théorie, CloudFormation est mieux intégré à AWS Lambda, mais dans la pratique, leurs interactions restent fragiles. Terraform disposait de bien meilleurs outils pour coder les connexions entre fonctions serverless et débuguer dans la foulée. Notons que Pivotal commercialise également une plateforme de Faas, qu’il oriente quant à lui vers le multi-cloud.
Trouver l’équilibre entre valeur, apprentissage et sécurité
Mike Roberts, cofondateur de Symphonia, une société de conseil en technologie, recommande aux développeurs de trouver le bon équilibre entre les avantages possibles, l’apprentissage nécessaire à la montée en compétence et la sécurité, avant de décider de mettre en œuvre le serverless.
Les principaux avantages de cette architecture portent sur la réduction des opérations de maintenance, une évolutivité et une meilleure gestion du rapport utilisation - coûts. Le serverless est particulièrement utile pour faciliter la création et le déploiement de nouvelles applications « from scratch » et recevoir rapidement un retour, positif ou négatif.
De bons points de départ
Une bon moyen de se tester sur le serverless est de développer des processus opérationnels qui améliorent le monitoring et automatisent la mise à l'échelle des applications. Ils sont généralement développés par les équipes d'exploitation et n'ont qu'un impact minimal sur le code de l'application en place. « Avec cette approche, le risque est minimal pour commencer », souligne Mike Roberts.
Lorsqu'un développeur se sent à l'aise, l'étape suivante consiste à implémenter des applications serverless pour des tâches hors ligne, comme des jobs cron. Cela peut faciliter l’éclatement d’un important job cron en plusieurs petites tâches. Elles peuvent ainsi être contrôlées avec plus de granularité – tout en tenant compte du fait que les fonctions serverless ont une durée limitée et ne constituent pas la meilleure option pour des batchs de longue durée.
Ce développeur peut ensuite mettre en œuvre des fonctions serverless qui apportent des composants temps réel aux applications et apprendre ainsi la programmation évènementielle. Cela permet également de tester des outils de messaging, tels qu’Amazon Simple Notification Service et Amazon Kinesis.
Enfin, le quatrième niveau d’expérimentation serait de mettre en place un écosystème serverless complet dans l'entreprise. C’est par exemple le cas de Bustle, spécialisé dans les médias en ligne. La société a adopté cette approche pour son back end. Selon elle, cela a permis aux développeurs d'en apprendre davantage sur la programmation événementielle. Si la technologie est bien mise en œuvre, les gains anticipés sont importants.
Et cette condition est ici clé. Car les applications serverless ont des contraintes différentes. On rencontre des pannes que les développeurs peuvent ne pas être en mesure de résoudre. Ce qui préoccupe d’ailleurs Mike Roberts : une défaillance du serverless peut aussi affecter d'autres secteurs de l’entreprise, y compris les applications qui ne sont pas serverless.
