Le tandem serverless – microservices : quels sont les bénéfices ?
Cet article montre que coupler le serverless aux microservices donne accès à certains avantages, notamment dans la gestion des processus métier et des applications.
Lorsqu'un nouveau modèle cloud émerge, il attire inévitablement l'attention.
Lorsque les fournisseurs de cloud ont commencé à offrir des services dits serverless, cela a suscité l'intérêt des clients. Aujourd'hui, pourtant, la confusion règne sur ce qu'est vraiment le serverless et comment il se rapporte aux microservices, aux fonctions, etc. Ce serverless est-il vraiment un modèle de service révolutionnaire, ou s'agit-il simplement d'une tendance très buzzy aux cas d’usage limités ? La réponse dépend de vos besoins.
Comment les services sans serveur et les microservices sont-ils liés les uns aux autres ?
Le serverless est un modèle d'hébergement cloud où une application, ou un composant, se charge et s'exécute à la demande. Parce que les composants serveless peuvent se charger à la demande, n'importe où et se dimensionner en fonction des besoins, rien n’est stocké entre chaque utilisation. Cela implique une structure d'application différente. Vous disposez d’un composant sans état, ou un composant qui ne se souvient de rien. Les composants sans état sont souvent désignés comme une fonction, un « lambda » ou un microservice.
Les microservices sans état marquent une évolution des modèles de développement : un changement vers une plus grande élasticité dans le déploiement des applications et un plus grand partage des composants. Cette tendance particulière porte sur l’hébergement de microservices sur des containers. Ces derniers proposent en effet des coûts inférieurs à ceux des machines virtuelles (VM) et les outils d'orchestration, tels que Kubernetes, se prêtent au déploiement de microservices.
Quand est-il judicieux d'utiliser à la fois les services sans serveur et les microservices ?
Articuler une application autour d’une kyrielle de composants est une mauvaise pratique car cela augmente la latence et la complexité opérationnelle. Pour les applications traditionnelles, on peut s'attendre à une progression des architectures de microservices. On peut également s’attendre à ce que les aspects de sécurité, de mise à l'échelle et de partage des microservices y trouvent refuge. En ce qui concerne le transactionnel, cette limite de composant devrait en freiner la croissance.
Si un changement doit intervenir dans la façon dont les applications utilisent les microservices, alors ce changement doit porter sur la façon dont ils sont invoqués. Sémantiquement parlant, si le modèle traditionnel appelle les microservices, alors le modèle alternatif doit quant à lui déclencher les microservices.
C'est là qu'il existe une convergence entre les microservices et les services serverless. Quand AWS et Microsoft ont présenté leurs services Serverless, ceux-ci ciblaient principalement les applications déclenchées par des événements - comme celles liées à l’IoT. Ces applications s'exécutent de façon intermittente et ne justifient donc pas l'utilisation de VM ou de serveurs cloud persistants. Cependant, l'IoT n'est pas le cas d’usage premier pour ces fournisseurs de cloud. La portée du serverless s’est élargie.
L'orchestration des applications et des processus métier permet de combiner microservices et serverless
Le premier cas d’usage du serverless et des microservices dans les entreprises porte sur l'orchestration d'applications et de processus métier pilotés par les événements. Presque tout ce qu'une entreprise fait avec l'informatique s’apparente à un ensemble chorégraphié d'étapes successives. Etapes qui se retrouvent au sein de plusieurs applications et souvent, utilisées par différentes équipes. Avec cette nouvelle approche, le serverless ou les microservices ne traitent pas les événements IoT, mais orchestrent les flux de travail des applications. Cette mission pourrait bien transformer tout le modèle du serverless.
Cette dimension comporte trois éléments. Premièrement, les applications doivent avoir la capacité de générer des événements et leurs déclencheurs. Deuxièmement, un mécanisme doit permettre d’activer les processus en fonction de ces déclencheurs. Enfin, les flux de travail ou les séquences de tâches - à la fois normales et anormales – doivent être définies pour structurer les workflows et les événements. Les fournisseurs de cloud disposent tous de ces trois éléments.
Les outils d'orchestration et d'intégration tels que Step Functions chez AWS ou Logic Apps de Microsoft permettent de séquencer les composants applicatifs en fonction des événements générés par d'autres applications. Microsoft propose par exemple des connecteurs qui permettent de déclencher des changements de documents dans Office. Ces connecteurs peuvent ensuite lancer d'autres applications et mettre à jour des bases de données. Ils peuvent également déclencher des fonctions et des microservices qui s'exécutent à la demande.
AWS et Microsoft proposent tous deux des cas d’usage pour illustrer l'utilisation de Step Functions et Logic Apps. Ces exemples montrent que les composants serverless et les composants microservices peuvent jouer les mêmes rôles dans l'orchestration d'applications métier et des processus que ceux traditionnellement joués par les ESB.
Au lieu de simplement contrôler ce qui est activé sur la base de l’analyse des données, on peut contrôler les processus sur la base de signaux provenant d'autres processus.
