Développement collaboratif avec des microservices – DZone

Dans une architecture de microservices, le code est divisé en petites unités. Ces morceaux de code peuvent être développés de manière isolée et envoyés indépendamment à la production, ce qui réduit les dépendances entre les équipes. Le résultat : un développement rapide des fonctionnalités et une mise sur le marché plus rapide.

Bien qu’une architecture de microservices apporte de nombreux avantages, la réalité est que ces avantages ont tendance à diminuer à grande échelle. En particulier, plus une organisation possède de microservices, plus il est difficile de s’assurer que les changements fonctionnent ensemble dans leur ensemble.

Collaborer et itérer plus tôt sur les contrats d’API de service rend le processus beaucoup plus rapide et plus efficace. Comprendre comment surmonter les défis liés à la collaboration entre les frontières des services est essentiel pour les organisations en pleine croissance qui ont besoin que leur architecture de microservices évolue. Ici, nous mettrons en évidence les avantages de la résolution de ce problème et présenterons un moyen efficace de rationaliser le développement de fonctionnalités parallèles.

Monolithes vs microservices

Les architectures basées sur les microservices sont devenues de plus en plus courantes, en grande partie parce qu’une base de code monolithique peut être extrêmement difficile et coûteuse à mettre à l’échelle.

Par exemple, avec un monolithe :

• Les modifications ne sont pas déployées rapidement car les développeurs ne peuvent pas travailler de manière indépendante.
• Le comportement de l’utilisateur final ne peut pas être testé en permanence ; au lieu de cela, il est testé à l’aide d’un modèle de cascade plus chronophage.
• Un problème avec une partie du code peut affecter ou casser l’ensemble de l’application.
• Chaque fois qu’un problème est détecté, le code peut devoir être annulé car il n’est pas toujours clair quel commit a causé la rupture.
• Plus il y a de changements, plus le nombre, la taille et la gravité des régressions logicielles sont importants, ce qui complique encore les tests.

Tester une application dans son ensemble au lieu de tester des éléments de cette application en cours de route ralentit le développement. Avec les microservices, de plus petits morceaux de code peuvent être développés, testés, déployés et mis à jour indépendamment, éliminant ainsi de nombreux goulots d’étranglement qui se produisent avec les monolithes et réduisant les risques.

De plus, le développement de fonctionnalités parallèles permet de publier simultanément plusieurs modifications. La possibilité d’apporter des modifications mineures de manière indépendante donne aux développeurs autonomie et flexibilité, réduit le temps de dépannage et accélère le déploiement. En conséquence, les applications deviennent à leur tour plus stables et résilientes.

Microservices et dépendances

Une architecture de microservices peut favoriser un modèle de livraison plus rapide, plus rentable et plus agile. Cependant, une architecture de microservices peut également avoir sa part de défis.

Les composants et les services peuvent agir comme des unités indépendantes et isolées dans une architecture de microservices, mais ont toujours des dépendances. Chaque unité de code communique avec d’autres unités de code pour échanger des données et des informations à l’aide d’API bien définies qui effectuent des appels externes. Alors que les microservices réduisent les dépendances en règle générale, plus le nombre de microservices est élevé, plus le nombre de dépendances est élevé.

Bien que ces dépendances n’affectent pas nécessairement les tests unitaires, elles affectent les tests approfondis qui doivent être effectués aux limites de l’API. De plus, tester l’interaction entre les microservices peut ralentir le processus de développement, car les développeurs passent traditionnellement beaucoup de temps à déboguer les problèmes au-delà des frontières. Enfin, ces dépendances peuvent être particulièrement difficiles à gérer lorsque le nombre de dépendances atteint des dizaines ou des centaines de microservices. La vitesse de livraison des logiciels en est souvent affectée.

Microservices et Collaboration

Le développement de nouvelles fonctionnalités implique généralement des modifications de plusieurs services, et les développeurs doivent collaborer au-delà des frontières des services afin de définir et de tester les API que d’autres équipes utiliseront. Cette collaboration devient délicate lorsque les développeurs ne peuvent pas intégrer les services dépendants au début du cycle de vie du développement.

La façon la plus courante de résoudre ce problème consiste à fusionner des modifications indépendantes, à déployer toutes les modifications dans un environnement de simulation, puis à prévisualiser et tester la fonctionnalité lors de la simulation. Cependant, chaque cycle d’itération implique le dépannage sur un environnement de staging partagé, la reproduction des problèmes localement et l’exécution d’un flux de travail CI/CD. Ce processus lent entrave la collaboration et le développement de fonctionnalités parallèles.

De plus, comme plusieurs équipes créent des fonctionnalités simultanément, l’utilisation d’un environnement de staging partagé devient un problème plus important. Tout bogue introduit a un impact sur les autres équipes qui dépendent de l’environnement partagé, ce qui limite le nombre de fonctionnalités pouvant être développées en parallèle à tout moment.

Comme solutions de contournement, certaines organisations clonent plusieurs copies d’un environnement de staging pour créer un pool d’environnements ou partager un environnement unique entre plusieurs équipes/fonctionnalités. Malheureusement, la première approche entraîne généralement une augmentation substantielle des coûts, et la seconde présente un goulot d’étranglement à mesure que le temps d’attente pour que l’environnement soit disponible augmente.

Mise à l’échelle des environnements pour les microservices

La clé pour améliorer la productivité de l’ingénierie autour du développement de nouvelles fonctionnalités est de fournir un retour d’information rapide et de haute qualité tout au long du cycle de vie du développement logiciel. Cependant, l’incapacité à faire évoluer les environnements qui permettent les tests de décalage vers la gauche entraîne les défis ci-dessus avec les dépendances et la collaboration. De plus, le clonage des environnements est d’un coût prohibitif, une nouvelle approche des environnements multi-locataires est donc nécessaire.

Une nouvelle approche pour faire évoluer les environnements de manière rentable consiste à utiliser la multilocation au niveau de l’application pour créer un grand nombre d’environnements haute fidélité qui existent en parallèle. Au lieu d’isoler l’infrastructure, cette approche isole les requêtes en étiquetant et en acheminant dynamiquement le trafic. Nous appelons ce modèle Environnements bac à sable.

À l’aide d’environnements Sandbox, les équipes peuvent créer de nombreux environnements haute fidélité au sein d’un cluster Kubernetes physique sans les dépenses d’infrastructure ou la charge opérationnelle liées à la duplication des environnements physiques. Dans ce modèle, l’environnement de base mis à jour en permanence par un processus CI/CD est partagé en toute sécurité entre toutes les Sandbox.

Le modèle d’environnements Sandbox présente de nombreux avantages :

• C’est rentable. Chaque environnement utilise un minimum de ressources, ce qui permet de créer des centaines voire des milliers d’environnements légers et éphémères.
• C’est rapide. Chaque environnement tourne en quelques secondes.
• Il garantit que les tests sont valides. Les versions « en cours de test » des services sont toujours testées par rapport à la ligne de base, qui est continuellement mise à jour.
• Il favorise la collaboration précoce. Les développeurs travaillant sur plusieurs référentiels de code peuvent collaborer en publiant et en consommant rapidement de nouvelles modifications d’API.

Une plus grande évolutivité avec les environnements Sandbox

L’accès aux environnements Sandbox avant la fusion permet des itérations et une collaboration très rapides au-delà des limites de l’API sans attendre les flux de travail CI/CD lents. Sans surprise, de nombreuses entreprises de premier plan, dont Uber, Lyft et DoorDash, utilisent des solutions Sandbox pour créer des microservices à grande échelle.

Étant donné que l’isolation est intégrée aux environnements Sandbox haute fidélité, les développeurs peuvent apporter des modifications de manière indépendante, collaborer au développement et aux tests d’API et exploiter rapidement les modifications des autres. Les fonctionnalités peuvent être testées préalablement fusionnées, et les problèmes peuvent être découverts et corrigés avec des boucles de rétroaction rapides.

Aujourd’hui, les équipes doivent faire évoluer le nombre d’environnements pour prendre en charge le développement de fonctionnalités parallèles, en particulier à mesure que le nombre de microservices augmente. Alors que l’approche traditionnelle des environnements de clonage n’est pas rentable, cette nouvelle approche Sandbox change le paradigme de collaboration et de test des microservices. Les environnements sandbox permettent le développement de fonctionnalités parallèles, favorisent la collaboration entre les équipes et sont rentables à l’échelle, c’est pourquoi leur utilisation devient de plus en plus courante dans les grandes et les petites organisations.