Webinaire : Introduction aux micro-services avec AWS

7 minutes

lire

Commençons par une idée fausse : "les microservices ne sont qu'un sujet informatique". C'est faux ! La mise en œuvre d'une architecture de microservices permet de résoudre des problèmes informatiques, certes, mais elle permet aussi d'aider considérablement l'aspect commercial d'une entreprise. Voyons comment tout cela est lié.

‍

Ancienne application

‍

Une plateforme patrimoniale est quelque chose de lourd à maintenir, à faire évoluer, et peut fonctionner à un coût élevé. Elle se compose souvent d'une grande base de données pour tout gérer, avec une isolation des composants proche de zéro, ce qui fait que l'application n'est en fin de compte qu'un gros bloc. Le résultat ?

Longs cycles de mise à jour : les mises à jour, les modifications et le développement de nouvelles fonctionnalités sur des infrastructures et des logiciels fortement couplés et interdépendants entraînent indubitablement une plus grande complexité et, partant, des cycles de mise à jour plus longs.
Problèmes opérationnels : comme nous l'avons vu au point précédent, la gestion d'applications patrimoniales monolithiques est complexe et entraîne une augmentation des problèmes opérationnels au fil du temps.
Bogues récurrents : le risque d'accumulation de dettes techniques dans un tel contexte est fortement accru - chaque modification, chaque correction du système risque de mettre en péril d'autres composants.

Dans le monde d'aujourd'hui, si un Product Owner demande à son équipe une nouvelle fonctionnalité relativement simple à développer et à mettre en œuvre, il ne sera pas "acceptable" d'avoir à attendre des mois pour que la fonctionnalité soit prête à être utilisée par le client. Les conséquences sont multiples : les clients doivent attendre plus longtemps pour utiliser les nouvelles fonctionnalités, le délai de mise sur le marché est plus long, la fourniture de valeurs aux clients prend plus de temps, ce qui, en fin de compte, nuit à l'entreprise.

L'impact sur les employés n'est pas non plus à minimiser : travailler avec de tels systèmes peut être néfaste à long terme, en conduisant l'équipe à adopter un état d'esprit plus conservateur, à résister au changement et à perdre en agilité.

‍

Approche et état d'esprit microservices

L'approche des microservices change directement du point de vue des personnes, une fois de plus la portée d'une telle approche n'est pas seulement "technique" mais aussi liée aux personnes. Dans le contexte d'une application monolithique, une équipe est divisée en fonction des capacités techniques : il y a une équipe d'administrateurs de bases de données, une équipe de back-end, une équipe de front-end, etc. Dans le contexte des microservices, les différentes équipes seront organisées en fonction des capacités commerciales : Équipe de gestion des utilisateurs, équipe de paiement, équipe de catalogue de produits, etc. Ces équipes auront pour objectif de s'organiser pour publier des microservices uniques et exposer ces services aux clients, qu'ils soient externes ou internes (c'est-à-dire aux autres équipes).

Cette approche pousse les différentes équipes à gagner en agilité, à développer des services indépendants les uns des autres et à s'orienter vers des fonctionnalités "autonomes". Chaque service sera basé sur une API et sera développé avec son propre modèle de données - si cela a du sens - afin de mieux s'adapter au cas d'utilisation. Par exemple, nous pouvons utiliser une base de données NoSQL pour gérer un catalogue de produits et une base de données relationnelle pour la gestion des utilisateurs - cela sera tout à fait réalisable dans une architecture orientée microservices et presque impossible d'avoir une telle approche dans une application monolithique.

Les microservices vous permettront également de faire un pas en avant en matière d'automatisation. Comme chaque service est indépendant, cela permet d'avoir des pipelines de déploiement automatisés dédiés à chaque fonctionnalité, gérés de bout en bout par l'équipe responsable de la fonctionnalité. Pourquoi est-ce hautement recommandé ? Tout simplement parce que le nombre de microservices augmentera au fur et à mesure que le nombre de fonctionnalités et de capacités d'un produit augmentera et que le déploiement d'un grand nombre de services manuellement à chaque fois deviendra une véritable plaie à faire et à opérer à long terme. Nous pouvons voir cela comme une limitation ou comme une opportunité de prendre la direction de l'automatisation :-) Je le vois clairement comme un moyen d'explorer le développement automatisé piloté par les tests, de faciliter les opérations en mettant en place des contrôles, des pipelines de déploiement automatisés, etc. et d'éviter trop d'opérations manuelles.

‍

Détour sur le conteneur

Mettons maintenant les conteneurs et plus particulièrement Docker sous les projecteurs et comprenons pourquoi il s'agit d'une solution substantielle dans le cas d'une architecture de microservices.

Docker est un outil permettant d'exécuter des applications dans un environnement isolé. Il offre des avantages similaires à l'exécution de machines virtuelles :

Votre application fonctionnera toujours dans le même environnement, ce qui évite les incohérences dans son fonctionnement. Si elle fonctionne sur une machine, elle fonctionnera de la même manière sur n'importe quelle autre machine ou serveur.
Il permet un meilleur sandboxing, en ayant des machines virtuelles dédiées pour chaque étape d'un projet (développement, test, pré-production, production...). Il apporte plus de sécurité et évite le risque de conflits entre différents projets ou différentes versions d'un projet.
Il facilite l'utilisation d'un projet par une autre personne - il n'est pas nécessaire d'installer les différents outils et dépendances dont un projet a besoin, mais il suffit de prendre la machine virtuelle déjà configurée.

Docker capitalisera sur ces avantages tout en supprimant le fardeau et la complexité que la gestion des machines virtuelles peut entraîner. Les machines virtuelles sont remplacées par des conteneurs. Le code, ainsi que l'environnement, prend place dans ces conteneurs, mais il diffère toujours d'une machine virtuelle complète.

Dans le cas des VM, chaque machine possède son propre système d'exploitation, y compris le noyau - qui est le cœur du système d'exploitation et gère les opérations de bas niveau. Cette configuration est encombrante pour la machine ou le serveur où sont hébergées ces VM.

Dans le cas des conteneurs, chaque conteneur utilisera le noyau de son hôte, le cœur du système d'exploitation sera donc partagé entre l'hôte et le conteneur. Tout ce qui se trouve au-dessus du noyau sera toujours divisé - cela représente en fait ce qu'est une distribution Linux, toutes ses spécificités sont contenues dans les couches au-dessus du noyau. Ainsi, docker s'appuie sur le système de fichiers UNIX pour créer des environnements isolés et créer un compromis, le sandboxing n'est pas aussi strict qu'avec une machine virtuelle mais il reste suffisant pour la majorité des cas d'utilisation. Aussi, le bénéfice qu'apporte docker compense largement : possibilité de lancer un conteneur en quelques secondes contre des minutes pour les VM, économie des ressources nécessaires au fonctionnement des conteneurs, optimisation de l'espace disque, pour n'en citer que quelques-uns.

Il y a trois concepts à comprendre lorsqu'on parle de conteneurs : le fichier Docker, l'image et le conteneur lui-même.

Le conteneur est une instance en cours d'exécution d'une image. Une image est un modèle d'environnement dont nous voulons obtenir un instantané à un moment précis. Elle contient le système d'exploitation, le logiciel et le code de l'application, tous regroupés dans un fichier. Les images sont définies à l'aide de Dockerfile, qui est un fichier texte contenant une liste d'étapes à effectuer pour créer une image. Ces étapes peuvent être la configuration du système d'exploitation, l'installation des logiciels nécessaires, la copie du fichier de projet aux bons endroits, etc.

La procédure est alors la suivante :

Un fichier Docker est écrit pour "BUILD" une image qui peut ensuite être "RUN" pour obtenir un conteneur réel.

Architecture

Comment mettre en place tout cela dans un contexte Cloud / AWS ? Faisons un simple PoC !

Nous nous appuierons sur trois services clés d'AWS :

Amazon API Gateway: ce sera le point d'entrée unique pour toutes nos API et microservices définis dans le back-end - ces services peuvent être internes ou externes. Il permet d'ajouter une couche d'abstraction pour chaque service - un client pourra accéder ou non à un service en fonction des règles qui seront définies au préalable.
Amazon Cognito: il sera utilisé pour tout ce qui est registre des utilisateurs. Avec Cognito, pas besoin d'avoir une base de données dédiée ni de configurer un LDAP, il suffit de mettre les utilisateurs (humains ou machines) dans AWS Cognito et la passerelle API sera en mesure de gérer l'authentification. Une fois qu'une requête est autorisée, elle est transférée à Fargate.
AWS Fargate: il s'agit d'un service qui gère les conteneurs sans qu'il soit nécessaire de disposer d'un serveur dédié exploité manuellement. Fargate gère également l'évolutivité - vers le haut ou vers le bas en fonction du nombre de requêtes envoyées au conteneur.

Voici à quoi ressemblera l'architecture :

‍

‍

Conclusion

Les microservices ne sont pas seulement une question de technologie ! C'est un moyen d'apporter aux entreprises plus d'agilité, un temps de mise sur le marché plus rapide, de favoriser l'automatisation et de stimuler l'innovation. En tirant parti de la puissance de l'informatique dématérialisée, vous disposerez de toute la pile technologique nécessaire pour développer une telle architecture de la meilleure façon possible. Planifier à l'avance votre transition vers une approche microservices est la première clé d'une mise en œuvre réussie du projet, n'hésitez pas à me contacter si vous avez besoin d'informations/conseils supplémentaires sur le sujet, je serai heureux de partager mon expérience avec vous !

‍

Ressources

N'hésitez pas à consulter la vidéo complète sur le sujet ci-dessous.

‍

Merci d'avoir lu cet article. Nous espérons qu'il vous a plu !
‍
Contactez-nous pour plus d'informations sur notre accompagnement et notre expertise !