Diviser pour régner : passer du monolithe à un modèle de microservices

30 septembre 2020 6 min. |

gsoft-blog-DIVIDE_CONQUER-hero-202010-1840x1040

Partager
cet article

Author

Dans l’univers de la technologie, qui dit croissance dit souvent complexité. Quand un logiciel né d’une petite équipe de développeurs agiles se transforme au fur et à mesure que l’équipe grandit, il devient presque impossible que quiconque ait réellement une vue d’ensemble. Le logiciel devient alors monolithique dans son architecture et, devient du même coup beaucoup plus difficile à gérer et à faire évoluer. En tant que développeur Full-Stack & Performance chez Officevibe, Etienne Lorthoy est à la tête d’un projet interne qui dure depuis octobre 2019, et qui vise à contrer l’obstacle de taille qu’est l’architecture monolithique de leur produit.

Alors, comment propose-t-il de s’y prendre pour simplifier la croissance et l’évolution d’Officevibe? En employant une stratégie bien connue : diviser pour régner. Dans le monde du logiciel, cette stratégie classique trouve son application dans la notion de microservices.

Partager cet article

Perspective d’employés

etienne
large-quotes-left

Plus le monolithe grossit, plus les gens vont se sentir dépassés, et plus ils vont développer une crainte que leur apport ait des répercussions qui causent des retards. Là, l’intérêt d’un microservice prend tout son sens : diviser pour régner; diviser pour croître.

dash-bar
Etienne Lorthoy

Développeur Full-Stack & Performance d’Officevibe, GSoft

large-quotes-right

Les faiblesses de l’approche monolithique classique

Une architecture de logiciel monolithique, de par son opacité, entraîne une série de problèmes en matière de développement, d’innovation et de gestion. « En tant que développeur », nous dit Etienne, « je dois connaître quasiment l’ensemble du monolithe pour être sûr que ce que je modifie ne compromette pas un autre aspect du logiciel. » La conséquence? Un plus grand risque de bogues et une perte considérable de temps et d’argent, qui sont consacrés à corriger des erreurs plutôt qu’à l’innovation du produit. Il faut tout prévoir et, si on se trompe, la perte de ressources peut s’avérer énorme. De plus, le temps de déploiement en souffre énormément et devient un obstacle important à l’extensibilité du logiciel. Bref, tout bouge au ralenti et les membres de l’équipe deviennent réticents à innover par peur de se tromper.

Dans une grande équipe comme celle d‘Officevibe, où personne n’a réellement une vue d’ensemble du projet, le défi est de savoir comment faire pour que l’information et le savoir-faire particulier au travail de chacun se rendent à la personne appropriée. Parce que sans ce partage d’information, le spectre des bogues coûteux à corriger resurgit; les gestionnaires de l’équipe sont appelés à gérer l’ingérable; l’équipe se décourage; et les employés découragés deviennent difficiles à retenir.

Les microservices : une approche pragmatique à la rescousse

Pour résoudre ce défi, l’approche microservices propose de décomposer le monolithe en éléments constitutifs. Chaque élément du monolithe se transforme alors en microservice qui, à son tour, entre en dialogue avec les autres éléments dans un écosystème de fonctionnalités. « Avec l’équipe d’Officevibe, on divise pour régner en s’assurant que chaque microservice ait un problème très spécifique à résoudre », nous dit Etienne.

Cette approche d’architecture du logiciel plus minimaliste permet alors de réduire la taille des équipes qui développent chaque microservice et de reproduire, en quelque sorte, la recette gagnante d’une jeune entreprise agile – permettant ainsi aux développeurs d’Officevibe d’avoir plus de contrôle, de créativité et de place pour innover.

bonhommes

La circulation de l’information et l’échange de savoir-faire entre les développeurs ne posent plus de problèmes puisque chacun peut facilement avoir une vue d’ensemble sur son bloc du projet. Du même coup, les risques de bogues diminuent, ainsi que le coût associé à leur correction. Le temps de déploiement est radicalement réduit et il devient facile de revenir en arrière si une innovation ne porte pas le fruit espéré. De plus, chaque équipe finit évidemment par se spécialiser, ce qui lui permet donc de devenir experte dans le domaine de son microservice. Cette expertise alimente la qualité de son travail, et, à l’échelle, la qualité de l’ensemble de l’écosystème de microservices.

Faire le grand saut : les éléments clés d’une transition réussie

Passer du monolithe à l'architecture de microservices est un défi en soi. La notion de microservices est assez récente et il n’y a donc pas beaucoup de guides pratiques pour les leaders chargés d’une telle transition. Chez Officevibe, la transition est entamée depuis maintenant un an, mais le niveau d’adoption de la nouvelle approche ne dépasse toujours pas les 20 %. « On a l’ambition de se rendre à 90 % d'adoption d’ici l’an prochain », explique Etienne.

Pour ceux qui cherchent à faire le grand saut, Etienne a deux grands conseils pour une transition réussie :

Dans un premier temps, les gestionnaires et les membres de l’équipe doivent tous bien saisir la théorie de l'architecture de microservices pour éviter les débats d’opinions en cours de route et bien saisir la grande variété d’outils, d’approches et d’alternatives à leur disposition pour relever un défi commun. À cette fin, il propose trois livres ressources : Domain-Driven Design Distilled, Monolith to Microservices et Building Microservices Applications on Microsoft Azure.

Dans un deuxième temps, il est important que la première itération de la mise en œuvre de la nouvelle structure soit efficace. « Il faut trouver le plus petit et le plus simple des projets pour la première implémentation », conseille Etienne. Mis à part le défi technique de la transition, un des plus grands défis demeure l’adoption de nouvelles approches, de nouvelles habitudes, de nouvelles façons de faire. Ainsi, afin de favoriser une culture orientée vers l’approche microservices, le déploiement du premier microservice ne doit pas dépasser quelques mois. Ce premier projet se doit aussi d’être simple à comprendre et facile à mettre en œuvre, non seulement pour permettre de valider nos propres hypothèses quant à la valeur concrète d’une nouvelle méthodologie, mais aussi afin que ce premier essai puisse intriguer et convaincre toute une organisation de remettre en question sa façon de travailler.

Parce que, comme le sociologue Daniel Bell le dit si bien : « La technologie, comme l’art, est un exercice de l’imagination humaine. ». Mais, avant de laisser libre cours à l’imagination et à l’innovation, il faut, bien sûr, commencer par comprendre le potentiel et la capacité de nos outils.

Partager ceci

Curieux de rejoindre nos équipes de développement ?