Une introduction à l’architecture en microservices & serverless

Une interview de Thomas Ruiz, Lead developer & Architect chez Neoxia

Bonjour Thomas, peux-tu te présenter ?

Je suis Thomas Ruiz, je viens du Sud-Ouest. Je suis d’abord diplômé d’entrepreneuriat & d’ informatique de l’université de Kent, puis d’Epitech en 2016. J’ai commencé comme alternant chez Neoxia il y a trois ans et je suis maintenant Lead dev & Architect.

Tu es devenu expert en microservices et serverless. Qu’est-ce que c’est ?

Un microservice est simplement une partie d’un système qu’on va isoler. On multiplie les services rendus fonctionnellement à de petites échelles pour répondre à des règles métier distinctes. Le concept est complémentaire de l’architecture serverless, qui signifie faire du développement en cachant la couche serveur. Des API tournent sur des services managés par AWS ou Google. Cela permet de réduire les coûts et ne plus avoir besoin de monitorer les serveurs, puisqu’on a plus peur qu’ils crashent.

“Chez Neoxia, on a travaillé avec beaucoup de clients différents sur ces sujets pour simplifier leurs monolithes”

A qui ces pratiques s’adressent-elles en priorité aujourd’hui ?

Il vaut mieux travailler avec des microservices sur des projets déjà existants, en extrayant des services petit à petit. Pour être efficace, il faut savoir quel service va avoir quelle utilité : avec un existant, on connaît les liens de communication entre les différents services. C’est plus facile pour identifier la maintenance et contenir les coûts de développement. Alors qu’au démarrage d’un projet, on aura du mal à savoir comment les microservices vont communiquer entre eux ou lequel sera responsable de telle ou telle règle métier. Quand il n’y a pas d’existant, il n’y a pas beaucoup d’intérêt à travailler en microservices.

Chez Neoxia, on a travaillé avec beaucoup de clients différents sur ces sujets pour simplifier leurs monolithes. On bosse en développement sur des microservices notamment en Node ou en Go, et on développe des Api avec les technos, entre autres, comme Lambda ou API Gateway de AWS.

A partir de quel moment sait-on qu’on a besoin de passer aux microservices ?

Lorsque chaque nouveau développement prend un temps considérable ou qu’on commence à avoir peur de toucher à l’existant. Par exemple, un de nos clients a développé un service d’abonnement en 2 mois au lieu de 2 semaines. Cela a agi comme une prise de conscience de leur côté.

“Plus on attend, plus le changement prendra du temps mais le passage est toujours possible et on constate rapidement les résultats en termes de délais, de maintenance, de coûts”

Est-ce que ca peut être trop tard ?

Ca n’est jamais trop tard. Plus on attend, plus le changement prendra du temps mais le passage est toujours possible et on constate rapidement les résultats en termes de délais, de maintenance, de coûts. Les développeurs sont beaucoup plus satisfaits de leur travail quand ils peuvent faire les choses rapidement. Pour être honnête, il vaut même mieux faire la migration “trop tard” que trop tôt.

C’est un équilibre très fin à trouver. Qui prend la décision ?

L’architecture est connue en théorie mais en pratique peu appliquée. Ca n’est jamais simple et le passage aux microservices demande un investissement conséquent. Il faut pouvoir l’assumer, car les bénéfices sont à long terme. C’est du niveau de la direction technique. Ca doit être fait lorsque le métier est gêné par les délais que prennent les développements.

Quelles sont les compétences à mettre en oeuvre pour réaliser une bonne architecture en microservices serverless?

Il faut avoir la capacité à appréhender un métier, connaître les limites de chaque domaine et les liens entre eux. C’est ensuite plus facile d’extraire le code lié à ces fonctionnalités-là. Par exemple, sur un site marchand, on va avoir des domaines métiers comme la gestion du catalogue des produits, les commandes, la gestion du stock. Chacun de ces points est un domaine métier. Il est nécessaire de s’entourer d’experts de ces domaines pour trouver les bonnes limites.

Techniquement, il faut bien connaître les API, leur architecture et être soucieux de bien tester son code. En termes de technologies, connaître Kubernetes et surtout Docker est très important. Faire des microservices avec Docker, c’est vraiment facile. On peut reproduire l’environnement sur sa machine et plus facilement voir comment les microservices vont communiquer. On va pouvoir ensuite le répéter en production plus simplement.

Eric Evans, auteur de Domain Driven Design (DDD), est l’évangéliste le plus connu de cette pratique. Je conseille fortement de lire son blog et son livre, qui pavent le chemin de cette architecture.

Un mot pour la fin ?

C’est très facile de se mettre au serverless, il suffit de se créer un compte sur AWS. Tout est gratuit ou presque. AWS Lambda supporte beaucoup de langages. En une semaine, on peut être opérationnel. Pour les microservices en revanche, il faut commencer avec quelqu’un qui s’y connaît car sinon, on se retrouve vite face à un mur.

Au final, bien s’entourer et se renseigner, c’est la clé. Les microservices ne sont pas adaptés pour tous les projets, mais peuvent en sauver d’autres. Bonne découverte !