Être consultant en informatique, c’est apporter son expertise de manière ponctuelle aux entreprises. Chez Cellenza, nos consultants et consultantes interviennent...
21 février 2020
BDX I/O 2019 #2 : Des microservices aux migroservices
Dans mon dernier article je vous présentais la session “Equiper sa voie” tenue par Thomas Pierrain lors de la conférence BDX I/O 2019. Pour ce deuxième volet de ma série d’article, je tenais cette fois à entrer davantage dans la technique, en vous parlant des Microservices et migroservices.
Des microservices aux migroservices (@fteychene)
Le sujet « Microservices » est un sujet sur lequel j’ai beaucoup lu, en plus d’avoir eu la chance de pas mal pratiquer. J’en sais suffisamment pour savoir à quel point le sujet est vaste et nécessite beaucoup de réalisation !
Bref, mon opinion peut se résumer avec cette simple phrase : c’est difficile !
Et très franchement, je suis allé à cette session un peu à reculons… Je me suis complètement trompé et je remercie la personne qui m’a motivé à y aller !
Cette session tenue par François Teychene est d’utilité publique, en plus d’être, je trouve, hyper drôle.
François est développeur et DevOps. Dès les premières minutes de la session, on peut confirmer que ce n’est pas une blague ! Cette session est clairement basée sur son expérience. Son retour est à la fois pragmatique et douloureux.
D’une manière générale, quand on est développeur depuis suffisamment longtemps, on se rend vite compte des différents phénomènes de mode qui vont et viennent assez régulièrement.
D’ailleurs, beaucoup de gens luttent contre ces derniers, vous devez vous rappeler des articles suivant :
On peut bien sûr en rajouter beaucoup plus, en effet le sujet « microservices » comme beaucoup d’autres est devenu victime de ce phénomène.
Définition du Microservices
François commence donc par une définition du Microservice en réaction au monolithe, il s’attarde surtout sur la différence de gestion de la complexité entre les deux styles d’architecture.
Il nous explique donc les trois grands types de complexités :
- Essentiel : on peut la définir comme la complexité issue du business. Faire sans, c’est tout simplement ne pas réaliser le projet. Pour faire votre site marchand, il faut pouvoir mettre des produits en ligne par exemple.
- Obligatoire : celle qui vient de vos contraintes. Votre site marchand, nécessite un serveur web.
- Accidentel : celle qui vient avec le temps, notamment lors des ajouts de features par exemple. Lors du rajout d’un nouveau moyen de paiement sur votre site marchand, des bugs sur le panier peuvent se produire.
Il conclut cette partie en nous expliquant comment les microservices atténuent les effets de ces complexités. Le mot clé ici est « atténuer » car aucune architecture sur cette planète n’a pour effet d’annuler, ni même de rendre négligeable les complexités présentées ci-dessus.
Le “Migroservice” : l’étape intermédiaire
François fait ensuite un rappel à la réalité avec le terme « migroservices », il représente souvent cette étape entre le monolithe et les microservices dans laquelle beaucoup d’organisations se retrouvent. En effet comme rappelé lors de cette session, ce style d’architecture demande un changement de mentalité radical en plus d’un investissement en temps et en argent très conséquent.
Il n’est donc pas dur de deviner ce qui se passe pour les organisations qui sous-estiment l’effort du passage vers les microservices, en plus de trop fortement limiter les budgets.
Finalement, de façon très habile, François nous explique point par point avec des exemples concrets comment on peut se retrouver sur une architecture migroservices. Il nous donne aussi ses bons conseils pour réussir à s’en sortir pour aller vers une architecture microservices.
En somme, le point le plus important à mon avis, c’est l’obligation de bien comprendre le business avant de commencer à développer. Cela passe avant tout par une implication de l’équipe de développement dans la phase de définition des règles métier mais aussi demande d’avoir un dialogue constant avec le business.
La gestion d’erreurs
C’est en effet le point sur lequel j’aimerais insister. François l’argumente en abordant ces deux aspects :
- Choisir la bonne abstraction.
- Un microservice doit être responsable de sa data.
Nous le savons tous, le sujet de l’abstraction est un sujet récurrent lorsque l’on développe. Dans une architecture en microservices il peut devenir handicapant et impacter la qualité de votre plateforme, cela quel que soit le domaine dans lequel vous évoluez.
Pour illustrer les impacts d’une abstraction prenons un exemple simple, celui-ci est en C#.
Ici je fournis une interface qui propose une méthode retournant une liste de produits pour un utilisateur au sein d’un microservice :
Voici effectivement les différentes interrogations qui peuvent surgir :
- En tant que microservice utilisateur de cette interface, n’ayant pas accès a l’implémentation, comment puis-je m’assurer que le résultat retourné n’est jamais “null” ?
- Est-ce que tous les “ints” sont des user “id” valide ?
- Si l’user “id” n’est pas valide, est-ce que cette interface me retournera un objet “null” ? Une liste vide ? Est-ce que je lance une exception ?
- Si derrière cette interface se cache un service. Cette interface me permet-elle de prendre avantage de la feature async / await maintenant standard lors d’appel réseaux en .NET ?
- Dans cette interface quel élément me signifie qu’une erreur réseau est possible ? comment s’est elle produite ?
- Lorsque j’appelle le service en question, si il met 10 minutes à me répondre ou au contraire si il est indisponible… Quel élément de cette interface me permet de le comprendre de façon explicite ?
Maintenant ajoutons un autre cas :
En plus des questionnements présentés plus haut, on peut maintenant se pencher sur la problématique de l’indépendance du service lors du déploiement. En effet, cette simple interface met en avant cette interrogation car si notre service pilote ajoute un produit, alors nous perdons la capacité de déployer le service derrière cette interface de façon indépendante (en plus d’avoir la réciproque du problème pour l’appelant).
Autant vous dire que ces questions, ne font que croître de façon linéaire ( si vous êtes chanceux…). Les questions à se poser, augmentent aussi en fonction du nombre de microservices (et d’instances déployés).
Pour conclure sur les microservices
D’autres points fondamentaux notamment sur les aspects OPS ou DevOps sont abordés lors de cette session. Si le sujet vous intéresse, je vous conseille vivement de prendre un peu de temps pour regarder la vidéo de cette session.
Si vous êtes débutant sur le sujet, pas de panique, l’introduction est qualitative et explique bien les fondamentaux. Pour les plus expérimentés, je vous invite aussi vivement à regarder la retransmission ! C’est en effet toujours un plaisir de voir un talk qui aborde le sujet de façon pragmatique, en plus de bien résumer les problématiques majeures de façon concise.
François conclut sa session en conseillant d’assumer la position « migroservices » pour aller vers du microservices, d’éviter le plat de spaghettis distribué et enfin fait un rappel sur certaines notions fondamentales ( “Bounding Context“, “Ownership”, …) nécessaires au microservices.
Pour ma part, je conclurai sur ces trois points :
- Les microservices sont difficiles à construire mais surtout encore plus difficiles à opérer.
- L’implication des OPS et la maîtrise des processus de livraison et de monitoring sont indispensables.
- L’implémentation de ce style d’architecture ne laisse pas place à l’enthousiasme et l’amateurisme sauf si vous êtes prêt à perdre beaucoup d’argent.
Bref, une fois de plus un super talk !
Car une fois n’est pas coutume, je vous donne rendez-vous prochainement pour découvrir le dernier article de ma série. Ce sera donc l’occasion de vous partager une dernière fois la troisième session de la conférence BDX I/O .
