Les technologies microservices et serverless sont les deux approches incontournables aujourd’hui si vous souhaitez améliorer le time-to-market de vos produits, ajouter de nouvelles fonctionnalités rapidement et réduire les coûts.

Les microservices sont un modèle d’architecture décentralisé dans lequel chaque application est décomposée en petits modules autonomes, ayant chacun une série de fonctions indépendantes (ou services) avec sa base de donnée, ses propres modèles, sa bibliothèque, ses tests, etc. Ils communiquent ensemble par des API.

Le Serverless est un modèle où le Cloud Provider assure toute la prise en charge du serveur en termes sécurité, load balancing, capacités, mise à l’échelle, journalisation et monitoring.

Les développeurs s’occupent de la partie coding et peuvent exécuter l’application sur tout ou partie du modèle sans serveur. L’intérêt est le paiement à l’usage car le propriétaire paye uniquement le temps d’exécution de l’application. Le serveur lui alloue des ressources et les récupère lorsque l’application n’est plus active. Le FaaS (Function-as-a-service) permet aux développeurs d’écrire le back-end et le front-end et de l’exécuter sur le serveur distant. L’application est ainsi construite comme un ensemble de fonctions. Chaque fonction a un objet et un « trigger » qui l’active. Elle est tout simplement désactivée lorsqu’elle n’est plus utilisée.

Quelles sont les différences entre microservices et serverless ?

La principale est que les microservices représentent une manière de concevoir une application ; tandis que le serverless représente davantage la manière dont on va exécuter l’application ou une partie de l’application. Ainsi, on peut tout à fait héberger des microservices sur du serverless !

Les microservices sont des fonctions qui peuvent s’inscrire dans la durée.

En revanche, les fonctions serverless, elles, ne sont jamais continues car elles nécessitent un événement déclencheur et ne peuvent pas contenir plus d’une fonction.

Quelles différences au niveau des équipes IT ?

Microservices

Lorsque vous êtes amenés à développer des produits avec des microservices, la planification est essentielle : natures et fonctions des microservices, comment ils vont interagir les uns avec les autres via des APIs, etc. Vous ne pouvez pas faire l’économie d’un architecte. Vous avez aussi besoin de développeurs et de testeurs qui connaissent l’environnement en microservices, même si le langage ou le framework de développement ne sont pas vraiment importants car le principe même des microservices repose sur le fait que vous pouvez utiliser les technologies que vous préférez (JS, Java, Pyhton, .Net pour les plus fréquentes).

Enfin, votre équipe devra avoir une véritable expérience projets en data et en cloud ; et être habituée à travailler en petites équipes.

Au niveau budget, les coûts des microservices sont un peu plus élevés lors de de la phase de développement mais l’équation s’inverse rapidement avec le temps. En effet, la maintenance est drastiquement réduite puisque vous pouvez rajouter rapidement et sans problème de nouvelles fonctionnalités (ou remplacer, supprimer). Pas de risque non plus de pannes qui peuvent se révéler catastrophiques, contrairement au monolithique, car si un microservice tombe en panne, le reste de l’application continue de fonctionner.

Serverless

Déjà, vous devez faire le bon choix pour vous en termes de service cloud provider (AWS Lambda, Microsoft Azure Functions, Google Cloud Functions pour ne citer que les plus connus). Puis, vous devez écrire toutes les fonctions et leurs déclencheurs (triggers).

Au niveau de l’équipe, ils doivent connaitre l’environnement du cloud provider que vous avez choisi mais aussi avoir de bonnes compétences en JavaScript ou Python.

Au niveau des coûts de développement, c’est la bonne surprise car déjà, c’est beaucoup plus rapide et surtout moins cher – et c’est d’ailleurs tout l’intérêt – d’héberger tout ou partie d’une application sur un serveur distant.  

Alors Microservices ou Serverless ?

Les microservices sont particulièrement recommandés si vous avez de grosses applications cœur métier stratégiques et que vous devez les faire évoluer constamment pour rester à la pointe. Idéal également si vous envisagez de moderniser des applications legacy devenues trop grosses, lourdes et ingérables en termes de maintenance.

C’est également recommandé dans le cas des applications big data qui par nature demandent d’exécuter des tâches à chaque étape pour fonctionner : collecte, traitement, stockage, etc.

Enfin, si vous avez plusieurs applications qui ont besoin de réutiliser des composants, une architecture microservices est également appropriée.

Le Serverless est lui bien plus approprié si vous avez besoin rapidement d’une application web ou mobile et qu’elle reste légère. C’est particulièrement adapté dans le cas d’une application qui parfois est inactive et d’autre connait des pics de trafic, puisque le serverless alloue (et facture) automatiquement des ressources en fonction de la consommation. Idéal également dans le cas d’une application IoT car le serverless est lui aussi basé sur le déclenchement d’événements.

les inconvénients ?

En Microservices, les tests peuvent se révéler laborieux car vous devez les tester indépendamment et tester la connectivité à l’échelle. Les API sont également un point de vulnérabilité à anticiper si elles sont mal configurées.

En Serverless, les tests peuvent aussi se révéler compliqués car il est difficile de savoir comment le code va fonctionner une fois déployé car vous ne pouvez pas vraiment répliquer un environnement serverless. Une fois d’une fonction est terminée, elle est mise en cache assez rapidement, ce qui peut créer des problèmes de démarrage à froid (délais).

Source : https://www.ideamotive.co/blog/serverless-vs-microservices-architecture