architecture agile

Les microservices : une architecture Agile — Première partie

 

L’ère numérique dans laquelle nous vivons présentement nécessite que nous apportions plusieurs changements dans nos manières de faire. Les entreprises qui perçoivent encore le développement logiciel comme un fardeau coûteux et non comme une force de frappe feront bientôt face à de nombreux défis importants. Pour surfer sur la vague technologique, les entreprises doivent pouvoir s’adapter à la réalité d’aujourd’hui. Pour rester compétitif, il faut pouvoir introduire des produits sur le marché plus rapidement, les améliorer vite et de la bonne façon, et offrir une excellente expérience à nos clients.

Pour parvenir à atteindre ces objectifs, les entreprises qui font du développement Agile doivent intégrer l’Agilité et l’adaptabilité à trois niveaux différents :

  • Les gens : ils doivent être à l’aise avec l’expérimentation et le changement;
  • Les processus : ils doivent être itératifs et optimisés pour l’apprentissage;
  • La technologie : elle doit soutenir la livraison rapide du produit.

L’Agilité technique ne peut être ignorée; des gens Agiles avec des processus Agiles ne peuvent pas pallier une technologie déficiente.

Évolution du développement Agile

Depuis la parution du manifeste Agile en 2001, les méthodes de développement ont beaucoup changé. En s’appuyant sur les principes du manifeste, plusieurs pratiques ont été suggérées pour faire face aux problèmes récurrents qui viennent fréquemment ralentir ou bloquer les équipes.

L’intégration continue (continuous integration) est issue de l’Extreme Programming. Elle vise à combiner toutes les composantes logicielles le plus tôt possible pour minimiser les efforts à investir pour régler les problèmes d’intégration. En y ajoutant les tests automatisés, le risque lié à la qualité est grandement diminué et la confiance envers le produit est constante. Si nous nous attaquons aux bloqueurs durant le processus de programmation, c’est un réflexe normal de continuer l’exercice pour celui de la livraison.

La livraison continue (continuous delivery) reprend le même concept et l’applique à une vision plus externe du produit. En définissant un processus de déploiement automatisé, l’incrément validé est livré le plus vite possible à l’utilisateur final. À ce niveau, nous devons prendre « l’incrément fonctionnel et utilisable » de Scrum au pied de la lettre! Nous pouvons ainsi profiter de la transparence sur le produit et sur le processus de développement au lieu d’avoir un environnement rarement fonctionnel et des utilisateurs déçus.

En permettant aux programmeurs de prendre en charge les déploiements en environnement de production, nous pouvons remettre en question la division traditionnelle entre les équipes de développeurs et celles des opérations. En combinant les deux types d’équipes, toujours avec le but d’optimiser la livraison du produit, nous pouvons nous permettre de nous attaquer à de nouveaux bloqueurs qui appartenaient jusqu’ici aux équipes opérationnelles. Cette fois-ci, nous avons de nouveaux outils venant des équipes de développement. Le mouvement DevOps appuie cette collaboration en encourageant les programmeurs à tenir compte d’une perspective opérationnelle dans la conception de leurs solutions, et en invitant les opérations à utiliser une approche plus scientifique aux problèmes habituellement gérés de façon procédurale.

Plusieurs des pionniers qui ont suivi cette évolution Agile se sont retrouvés avec un processus de livraison optimisé, mais également avec une solution qui se livrait en un seul morceau. Au fur et à mesure que la complexité et l’ampleur de la solution grandissent, cette architecture ralentit le développement de nouvelles fonctionnalités et devient un obstacle à l’extensibilité que l’infonuagique (cloud computing) peut offrir. Certaines compagnies, comme SoundCloud, ont découvert qu’en divisant leurs applications monolithiques en plusieurs microservices, elles peuvent mieux soutenir leur livraison Agile et instaurer une culture DevOps. Les microservices entrent donc en jeu…

ms1

 

ms2

Qu’est-ce qu’un microservice?

Avant de s’attaquer au concept de microservice, il est important de comprendre ce qu’est une architecture monolithique. Imaginons que vous créez présentement une application de covoiturage. Avec les différentes composantes d’architecture (base de données, interface utilisateur, logique d’affaires et quelques services provenant de tierces parties), nous nous retrouvons avec une architecture hexagonale :

ms3

Plus le temps avance, plus cette application devient grosse et vous avez rapidement besoin de faire face aux besoins d’évolution de certaines parties de l’application pour être en mesure de soutenir la charge de travail. C’est une tâche relativement simple, nous n’avons qu’à installer l’application (ou des parties de celle-ci) sur plusieurs serveurs derrière un système de gestion de charge (load balancer). En automatisant cette partie, nous pouvons profiter du concept d’élasticité et avoir une solution qui s’adapte à la charge demandée.

Par contre, comme chaque installation demeure exposée aux erreurs qui pourraient s’introduire dans le code commun, il y a toujours une réticence à apporter des changements architecturaux puisque nous ne voulons pas déstabiliser l’ensemble du système. De plus, nous nous disons qu’une fois la main prise dans l’engrenage, il faudra faire migrer tout le code pour utiliser cette nouvelle technologie.

En résumé, l’application est peut-être sur plusieurs environnements, mais elle est quand même considérée comme un tout. Les microservices agissent plutôt comme des mini-applications qui ont leur propre architecture et qui s’adressent seulement à un domaine d’affaires. Les équipes de développement peuvent alors travailler sans avoir peur d’avoir une incidence sur le reste de l’application, pourvu que le contrat de l’interface applicative (API) soit respecté.

Il devient plus intéressant d’essayer de nouvelles technologies et d’expérimenter, car la communication entre chaque module est configurable. Cet avantage nous rapproche de la pratique des tests A/B, qui consiste à expérimenter avec plusieurs variantes d’un même module afin de déterminer la version qui donne les meilleurs résultats.

Aussi, en gardant une base de données dans un environnement séparé pour chaque module, nous nous retrouvons avec une application qui est immuable, qui n’a pas de données nécessaires au traitement en mémoire. Dans ce contexte, il est possible de créer des conteneurs (avec Docker par exemple) et de bénéficier d’un environnement de serveur très léger, facile à migrer par les équipes de développement, d’opération et d’infrastructure. Comme les dépendances logicielles sont gérées par les conteneurs, il n’y a plus lieu de s’inquiéter de la présence de toutes les composantes nécessaires avant d’installer l’application.

Comme la plupart des pratiques de développement logiciel, utiliser des microservices n’offre pas une solution à tous les problèmes. Par contre, en les utilisant graduellement pour se connecter à des systèmes et à des services existants, ils offrent une Agilité et une rapidité de développement qui permet aux entreprises d’avancer et d’innover avec des moyens qui n’étaient pas disponibles jusqu’à présent.

Dans la seconde partie de cet article qui paraîtra prochainement, nous continuerons d’explorer les microservices et notamment comment nous pouvons utiliser le Domain Driven Design pour les créer.

One response to “Les microservices : une architecture Agile — Première partie

Leave a Reply

Your email address will not be published. Required fields are marked *