Définissez les problématiques et les besoins
Avec l'essor de l'utilisation des applications gourmandes en ressources (streaming vidéo, banques, musique, e-commerce, etc.), les entreprises sont confrontées à des challenges liés à la performance de ces services, au coût de l'infrastructure technique et au coût du développement et de la maintenance.
Problème n° 1
Comment faire en sorte que les applications proposées en ligne soient toujours disponibles et ne souffrent jamais de coupure ou de ralentissement, quelle que soit l'affluence des utilisateurs sur celles-ci ?
Prenons un exemple : si une entreprise a pour activité l'e-commerce de vêtements, comment peut-elle faire face à l'explosion du nombre d'utilisateurs se connectant sur son site à 8 h du matin le premier jour des soldes ? Ajouter 200 serveurs pour supporter l'affluence pendant 2 heures ? Ce n'est pas réalisable, ou du moins c’est très coûteux.
Une solution est d'utiliser le cloud. Celui-ci permet d'augmenter et de diminuer le nombre de ressources nécessaires au fonctionnement d'une application à la demande. Cette solution paraît idéale, car il suffit à notre entreprise d'e-commerce d'augmenter les ressources à 8 heures du matin et de les diminuer à 10 h, sans avoir à acheter de nouveaux serveurs, à les installer et à les maintenir, pour finalement ne plus en avoir l'utilité lorsque l'affluence diminue.
Cependant, vous vous en doutez, il y a un problème : il faut que l'application soit conçue de façon à ce qu'elle puisse être scalable, c'est-à-dire capable de s'étendre sur plus de ressources (plus de serveurs, de disques durs, de bases de données), tout en gardant une parfaite consistance dans ses données et une cohérence dans son comportement. Or, l'application de cette entreprise, conçue sur une architecture plus classique (3-tiers, par exemple) est très difficilement scalable.
Il faut donc envisager, dès le départ, une autre approche dans la conception de l'application, afin que celle-ci soit "Cloud-native", c'est-à-dire conçue pour fonctionner et profiter pleinement des avantages qu'offre le cloud.
Problème n° 2
Les entreprises se livrent à une "guerre de la mise à jour". Il faut que l'entreprise soit capable de faire évoluer son application de façon très fréquente, et de répondre rapidement aux nouvelles fonctionnalités que propose la concurrence.
Or, avec une application traditionnelle, le processus de mise à jour est long et compliqué car il faut mettre à jour toute l'application. Il est ensuite nécessaire de retester et de déployer l'application complète. Cela est dû à la forte interdépendance au sein d'une application. Par exemple, celle-ci peut reposer sur une seule base de données qui regroupe les tables de tous ses composants. Ces composants peuvent eux-mêmes être liés par des clés étrangères et des triggers, qu'on ne peut pas modifier à la légère (oui, ça existe encore, et vous ne pouvez pas imaginer dans quelle ampleur !).
Les entreprises sont donc obligées de passer à des architectures permettant de faire des mises à jour qui visent des composants ciblés, très rapidement, de façon fiable, et sans se soucier des éventuelles conséquences sur le reste de l'application.
Problème n° 3
Les technologies utilisées pour développer ces applications évoluent très vite, et les nouveautés offrent parfois des avantages énormes. Comment les entreprises peuvent-elle s'adapter rapidement pour tirer profit de ces évolutions ?
Imaginez une entreprise qui permet de placer des transactions sur les marchés boursiers. Nous parlons ici de millions d'opérations par seconde. Il faut donc être capable de vendre et acheter très vite, à la microseconde près, lorsque la fluctuation d'une action est favorable. L'application de cette entreprise repose sur un algorithme puissant écrit en Java. Un beau matin, si elle ne s'adapte pas, elle perdra des clients car elle sera dépassée par la concurrence, qui mettra en œuvre un algorithme très rapide en Node.js dans les semaines suivantes...
Pour éviter ce genre de situation, l'entreprise doit adopter une architecture qui lui permettra de passer d'une technologie à l'autre sur des portions individuelles de son application, très facilement.
Il faut donc que les entreprises conçoivent leurs applications dès le départ à partir d'architectures répondant à ces besoins, et qui soient parfaitement adaptées au cloud. C'est ainsi que l'architecture Microservices est apparue, apportant une réponse concrète à toutes ces préoccupations et la promesse d'obtenir, au bout, des applications dites "Cloud-native".
Comprenez le principe de l'architecture Microservices
L'architecture Microservices propose une solution en principe simple : découper une application en petits services, appelés Microservices, parfaitement autonomes, qui exposent une API REST que les autres microservices pourront consommer.
La figure ci-dessus représente un schéma simplifié d'une application basée sur l'architecture Microservices. Cette application affiche par exemple un produit à vendre. Cette fiche produit est donc constituée par exemple d'une photo, d'un descriptif et d'un prix. Dans le schéma, l'interface utilisateur fait appel à un microservice pour chaque composant à renseigner. Ainsi, celle-ci peut faire une requête REST au microservice A, qui s'occupe de la gestion des photos des produits, afin d'obtenir celles correspondant au produit à afficher. De même, les microservices B et C s'occupent respectivement des descriptifs et des prix.
Vous voyez alors, à travers cet exemple, quelle est l'idée générale de l'architecture Microservices. Dans une architecture traditionnelle, vous avez une application au format WAR qui comporte tous les composants. Lorsqu'un utilisateur demande une fiche de produit, l'application applique sa logique interne et va puiser dans une base de données, puis produit un HTML final.
Dans l'exemple que je vous ai donné, l'interface utilisateur est elle-même un microservice qui a pour responsabilité d'appeler les autres microservices, et de rassembler donc cette "fiche produit" partie par partie avant de la servir à l'utilisateur final.
Chaque microservice est parfaitement autonome : il a sa propre base de données, son propre serveur d'application (Tomcat, Jetty, etc.), ses propres librairies et ainsi de suite. La plupart du temps, ces microservices sont chacun dans un container Docker, ils sont donc totalement indépendants y compris vis-à-vis de la machine sur laquelle ils tournent.
Voici une vue plus détaillée de notre architecture :
Bien entendu, d'autres éléments viennent s'ajouter dans le cas d'une architecture Microservices réelle. Néanmoins, nous allons partir de ce cas simplifié, et nous allons l'enrichir au fur et à mesure de l'avancement du cours.
Répondez à ces problèmes avec l'architecture Microservices
Chacun des microservices dans notre schéma, comme je l'ai dit plus tôt, est parfaitement autonome, ce qui fait que notre application peut parfaitement profiter de tout ce que le Cloud peut offrir. Ainsi, on peut, par exemple, dupliquer le microservice A sur plusieurs serveurs. Le microservice qui s'occupe de l'interface utilisateur (UI) va appeler une des instances de ce service et recevoir la même réponse, quelle que soit l'instance choisie. Nous verrons plus tard qu'il existe d'autres microservices spécialisés dans le dispatching des requêtes vers les différentes instances. Finalement, notre application est parfaitement élastique : vous pouvez lui envoyer 5 utilisateurs ou 5 millions, il suffit d'augmenter ou de diminuer le nombre d'instances en service.
Quand on voudra mettre à jour l'application, il suffira de cibler directement le microservice responsable de la fonctionnalité en question. Ainsi, si on dispose d'une nouvelle technologie de pricing qui permet de proposer des prix compétitifs en fonction de la concurrence en temps réel, tout ce qu'il y a à faire est de modifier le microservice C et de le redéployer. À aucun moment vous n'aurez à vous soucier de l'ensemble de l'application ou de quelles répercussions vos changements pourraient avoir sur celle-ci. De cette manière, le processus de mise à jour est d'autant plus rapide que les microservices sont par nature petits et relativement simples. Le risque de bug ou d'indisponibilité de l'application devient très bas, car vous n'avez pas à builder votre application dans un grand WAR, puis à croiser les doigts pour que le nouveau code soit parfaitement compatible et fonctionne correctement une fois déployé.
Encore une fois, du fait du cloisonnement complet de nos microservices, on peut utiliser dans chacun la technologie qu'on veut. Le microservice A peut être en Java alors que le B est en C++ ou Node.js, l'essentiel étant qu'il expose une API REST. Ceci offre un avantage énorme à l'entreprise, qui va pouvoir tirer profit des dernières avancées technologiques sans limite de langage, de framework ou d'environnement.
Cerise sur le gâteau, les équipes de développement dans une entreprise deviennent beaucoup plus autonomes, car il n'y a plus lieu de consulter toutes les équipes pour concrétiser une idée et vérifier sa compatibilité technique avec ce que font les autres. Les équipes vont pouvoir travailler de façon autonome et aller au bout de leurs projets, avec la technologie et les outils de leur choix. On a donc ici un gain de temps et d'innovation.
Faites la différence entre SOA et MSA
En effet, l'architecture Microservices (MSA) est une évolution de la SOA, dans laquelle les concepts de la SOA ont été repris et poussés à l'extrême. D'ailleurs, dans un service de l'architecture SOA, vous pouvez trouver des éléments typiques d'un microservice. Pour autant, cela n'en fait pas un microservice en bonne et due forme.
Quelles sont les différences entre SOA et MSA ?
Les services dans l'architecture Microservices sont très spécialisés. Ils s'occupent d'une et d'une seule fonctionnalité, alors que dans la SOA, la pratique est de créer des services qui gèrent un domaine, par exemple un service de gestion des utilisateurs. Dans la MSA vous aurez plutôt un microservice de gestion des rôles des utilisateurs, un autre pour l'ajout / suppression / suspension des utilisateurs, etc. La taille des services dans une MSA est souvent beaucoup plus petite que dans une SOA.
Dans la MSA, le couplage faible est primordial, à savoir que chaque microservice doit être très indépendant à tous les niveaux. Chaque microservice possède sa propre base de données, alors que dans une SOA, il est courant de trouver une base de données commune à plusieurs services. Théoriquement, ce n'est pas censé être le cas, mais la pratique est différente. Cela s'explique par le fait que la SOA a été utilisée comme une approche pour moderniser les anciens systèmes. Or, manipuler ou redesigner les bases de données est tellement délicat que, souvent, on se contente de les optimiser. Néanmoins, ne soyez pas surpris si vous rencontrez une MSA où il y a une base de données partagée. Une des pratiques consiste à avoir une base de données partagée mais avec, par exemple, des "schémas" différents qui garantissent une indépendance totale. Les résultats sont les mêmes, il y a une relation d'exclusivité entre le microservice et ses données, car le seul moyen d'accéder à celles-ci et de passer par ce microservice.
La SOA vient souvent avec un grand ESB central qui s'occupe des messages et de leur transformation. Vous devinez bien que si l'ESB, qui relie tous ces services, est en panne, c'est tout le SI qui l'est aussi. Dans une MSA, on utilise un simple système très léger de messaging, qui n'est d'ailleurs pas toujours nécessaire. De plus, il est tout à fait possible d'appeler un microservice directement si ce système de messages ne fonctionne pas, car il n'a pas de rôle de modification ou d'adaptation des messages, mais un simple rôle de gestion de leur queue et de dispatching.
La SOA accepte que ses composants (services et autres) communiquent avec des protocoles différents, l'ESB s'occupant ensuite d'adapter et de transformer. La MSA tend à obliger à utiliser un seul protocole et à s'y tenir. On a bien sûr moins de liberté, mais l'architecture s'en trouve simplifiée tout en se débarrassant de l'ESB.
Ces divergences engendrent des tendances différentes dans l'utilisation de certaines technologies, renforçant, de fait, le fossé entre les 2 architectures ; par exemple, l'utilisation de Docker est très courante dans la MSA, alors qu'elle est anecdotique dans la SOA. Il en est de même pour l'utilisation des PaaS (Platform as a Service) qui offrent d'énormes avantages, et qui sont là aussi très peu utilisés dans la SOA.
En résumé
Les microservices permettent de rendre une application scalable pour s’adapter au nombre d’utilisateurs.
Les microservices se basent sur un couplage faible entre les composants.
Les microservices communiquent entre eux via des requêtes HTTP/HTTPS en suivant le protocole REST.
La taille des services dans une MSA est souvent beaucoup plus petite que dans une SOA. Dans la MSA, le couplage faible est primordial, à savoir que chaque microservice doit être très indépendant à tous les niveaux. Chaque microservice possède sa propre base de données, alors que dans une SOA, il est courant de trouver une base de données commune à plusieurs services.
Avant de s’attaquer à l’écriture de nos microservices, nous allons présenter SpringBoot, qui est le framework Java de référence. C'est parti pour le prochain chapitre !
