Micro Services

Tutoriel pour apprendre sous quelles
conditions utiliser les microservices
Par Cherifa GHERSI AMARZOURGUI
Date de publication : 25 octobre 2017
Les microservices attirent de plus en plus l'attention des architectes. Il s'agit d'un pattern
architectural semblable au SOA (architecture oriente services), la diffrence tant que les
microservices ont tendance valoriser des services plus restreints.
Dans ce tutoriel, nous allons dcouvrir ce qui se cache derrire ce terme.
Commentez
Tutoriel pour apprendre sous quelles conditions utiliser les microservices par Cherifa GHERSI AMARZOURGUI
I - Introduction..............................................................................................................................................................3
II - Une volution des SOA ?...................................................................................................................................... 3
II-A - Microservices.................................................................................................................................................4
II-A-1 - Les caractristiques..............................................................................................................................4
III - Avantages des microservices............................................................................................................................... 5
IV - Conditions d'utilisation.......................................................................................................................................... 6
IV-A - Dploiement................................................................................................................................................. 6
IV-B - Hbergement peu coteux.......................................................................................................................... 7
IV-C - Erreurs viter............................................................................................................................................7
IV-C-1 - Dcoupage.......................................................................................................................................... 7
IV-C-2 - Monitoring............................................................................................................................................7
IV-C-3 - Difficult de la dfinition des microservices........................................................................................8
V - Du monolithique aux microservices.......................................................................................................................8
VI - Les microservices pour une nouvelle application................................................................................................ 9
VII - Conclusion........................................................................................................................................................... 9
-2-
Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par
les droits d'auteur. Copyright 2017 Cherifa GHERSI AMARZOURGUI. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents,
images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.
http://soat.developpez.com/tutoriels/web/conditions-utilisation-microservices/
I - Introduction
L'ide principale est de dcouper une application monolithique en morceaux composables. Ces morceaux devront
travailler ensemble pour permettre l'ajout de nouvelles fonctionnalits plus rapidement et de faciliter la maintenance.
Chaque composant est dvelopp sparment, afin que l'application soit le produit de tous les microservices
combins.
Cette ide de sparer une application en plusieurs morceaux n'est pas nouvelle, il existe une autre architecture
qui utilise le mme concept : l'architecture oriente services SOA , modle d'interaction applicative mettant en
uvre plusieurs services. Il faut noter que les microservices comportent de nombreux avantages, mais aussi des
points faibles non ngligeables. En les utilisant l o il ne faut pas, nous risquons d'avoir plus d'inconvnients que
d'avantages et de ne pas profiter de toute la puissance qu'ils offrent.
Nous allons commencer par dfinir l'architecture oriente services SOA , base des architectures microservices.
II - Une volution des SOA ?
L'architecture oriente services est une solution logicielle distribue, se composant de trois acteurs principaux :
le fournisseur de service : acteur responsable du dveloppement du service, de son dploiement, de son

excution ;
le consommateur de service : acteur utilisant les services en fonction de ses besoins ;
le registre de services (service broker) : acteur qui enregistre les informations et permet de faire le lien entre
consommateurs et fournisseurs. Les fournisseurs publient les services dans ces registres, qui sont ensuite
consults par les consommateurs.
On parle d'volution puisque les microservices ont de nombreux points communs avec le SOA. Ils sont tous deux
ddis la sparation des modules grce des services. Les microservices et le SOA ont cependant plusieurs
diffrences, notamment au niveau de la dfinition des services, des mthodes, de leur cration, mais aussi de leur
tendue et de leurs principes. Il est intressant de noter que parmi les entreprises qui utilisent actuellement les
microservices, certaines, comme Netflix, considrent qu'elles font du SOA. Les diffrences entre ces deux approches
tant faibles, il est possible de dire que les microservices sont une manire particulire de faire du SOA.
-3-
II-A - Microservices
Un microservice est un service concentr sur une seule fonctionnalit, la plus simple possible ; l'interface expose
doit l'tre galement. Mme s'il peut exister des interdpendances entre les diffrents microservices, chacun doit
tre dploy sparment.
II-A-1 - Les caractristiques
Concentr sur une seule fonctionnalit
Un microservice implmente et est responsable d'une seule fonctionnalit dans tout le systme. Une fonctionnalit
peut tre une fonctionnalit mtier contribuant l'objectif du systme, ou une fonctionnalit technique utilise par
plusieurs fonctionnalits mtier.
Dploiements individuels des microservices
Chaque microservice doit tre dployable indpendamment des autres. Ce point est important : si l'on veut changer
un microservice en particulier ou le mettre jour, il faut tre capable de le faire sans toucher aux autres microservices
ni affecter leur excution.
Le systme doit continuer fonctionner correctement durant la mise jour du microservice en question, ainsi qu'aprs
l'avoir redploy.
Constitution d'un ou plusieurs processus
-4-
Un microservice peut correspondre un ou plusieurs processus. Il doit obligatoirement tre hberg sur des
processus indpendants. En d'autres termes, il ne doit pas partager un processus avec un autre microservice.
Il peut tre en revanche constitu de plusieurs processus, notamment dans le cas d'un accs une base de donnes.
Autrement dit, seul ce service peut accder cette base de donnes. C'est une faon d'viter au maximum les
interdpendances entre les microservices.
Par exemple si l'on dveloppe deux microservices sur le mme processus, nous risquons d'avoir des
interdpendances qui vont conduire l'obligation de dployer les deux en mme temps, ce qui est contraire aux
caractristiques des microservices.
Un microservice, une base de donnes
Un microservice ne peut pas utiliser la base de donnes d'un autre. Il doit avoir sa propre base de donnes o sont
enregistres les donnes dont il a besoin pour qu'il soit compltement indpendant des autres.
Par exemple, si le microservice B veut utiliser une donne enregistre dans la base de donnes A, il lui faudrait
passer par l'API du microservice A et ne peut dans aucun cas passer directement la base de donnes A.
La taille des microservices
Comme l'indique le nom micro , les microservices doivent tre concentrs sur une seule et unique fonctionnalit,
de faon ce que leur dveloppement et leur maintenance puissent se faire par des quipes de petite taille.
Remplaable
On doit pouvoir remplacer n'importe quel microservice du systme dans un temps raisonnablement court.
III - Avantages des microservices
Utiliser les microservices amne des avantages divers provenant principalement de l'indpendance des quipes
dveloppant les services ainsi que de leur taille. Ils peuvent donc limiter les problmes les plus frquents rencontrs
par de grandes applications tout en permettant une grande souplesse dans le dveloppement et le dploiement.
Htrognit technologique
-5-
Un microservice n'a pas besoin de connatre la technologie utilise par les autres microservices, il est donc tout
fait possible d'avoir des services n'utilisant pas les mmes technologies. Cela permet d'utiliser une technologie
plus adapte pour un problme donn si ncessaire, mais aussi d'utiliser plus facilement de nouvelles technologies.
Cependant, multiplier le nombre de technologies peut avoir des effets ngatifs sur la mobilit des dveloppeurs entre
les services. Il vaut donc mieux limiter cette option aux cas o cela est ncessaire.
Rutilisabilit
Dans le cas d'un service ne faisant que rendre disponible une API web, il est facile pour un autre service de le
consommer, et ce quels que soient le langage, la plateforme, ou le systme d'exploitation utilis. On peut galement
utiliser ces services dans diffrentes applications si ncessaire. De plus, il devient plus facile de faire diffrentes
interfaces pour le web et le mobile.
Maintenabilit
L'utilisation des microservices peut rendre de gros logiciels plus maintenables. Il permet en effet d'viter de devoir
grer un volume de code trop important. Leur facilit de maintenance peut les rendre avantageux financirement
parlant.
Rsilience
Pour chaque service contenant au moins un processus, l'interruption d'un service n'empchera pas les autres de
fonctionner. L'application n'est soit plus en marche, soit interrompue, mais peut tre dans des tats intermdiaires.
Cela permet donc de rduire le temps o l'application est inutilisable dans son ensemble, au profit d'un moment o
l'application fonctionne partiellement, et peut dans la plupart des cas rpondre aux besoins du client.
Scalabilit
La plupart du temps, une partie de l'application ncessite plus de ressources que le reste. Dans le cas d'une
application monolithique, il faut augmenter les ressources utilises pour toute l'application.
Les microservices n'ont pas ce problme, puisque chaque service se voit accorder des ressources de manire
indpendante. Il est donc tout fait possible d'augmenter les ressources uniquement pour les services concerns.
Les microservices permettent donc d'avoir une gestion plus fine des ressources disponibles et peuvent rduire le
cot d'une monte en charge verticale. Aussi, ajouter de nouvelles fonctionnalits une application base sur les
microservices se fait simplement en ajoutant de nouveaux services.
Testabilit
Chaque microservice n'tant responsable que d'une fonctionnalit, il est plus facile de le tester ; la simplicit des
services aide leur testabilit. Des difficults pourront cependant arriver en testant les interactions entre les diffrents
services. Si l'API teste a t bien dfinie, cela ne devrait pas tre un problme.
IV - Conditions d'utilisation
Les microservices ncessitent la modernit de l'organisation et des technologies employes. Pour les utiliser de la
manire la plus optimise possible, il est important de parler de dploiement et d'organisation humaine.
IV-A - Dploiement
Le nombre important de services peut poser des problmes de dploiement. Si tel est le cas, il faut les rsoudre
au plus vite afin de faciliter l'avancement du projet et de pouvoir profiter de manire efficace des avantages de ce
genre d'architecture. Nous avons souvent recours au dploiement continu, pratique visant rduire le plus possible
le temps de cycle, c'est--dire le temps coul entre l'criture d'une nouvelle ligne de code et l'utilisation relle de
ce mme code par des utilisateurs finals.
-6-
L'quipe s'appuie sur une infrastructure automatisant l'ensemble des tapes de dploiement (ou mise en
production ), de sorte qu'aprs chaque intgration qui se solde par des tests russis, notre application est mise
jour. La meilleure des pratiques adopter dans ce cas-l est de dvelopper une culture de l'automatisation.
Pour avoir plus de dtails sur la manire de pouvoir grer tous ces dploiements, on peut s'appuyer sur le DevOps,
le continuous deployment, le continuous delivery et le continuous integration, le but tant d'tre capable de livrer
rapidement une application faible cot, et cela importe plus que la mthode employe.
IV-B - Hbergement peu coteux
Pour faire des microservices, il faut dployer beaucoup plus d'applications indpendantes que pour une application
monolithique. Si des mcanismes ne sont pas mis en place, les microservices deviendront vite beaucoup trop chers
par rapport leur bnfice.
Les services peuvent tre hbergs sur le mme serveur, mais ceci est gnralement considr comme une
mauvaise ide, car contribuant un couplage matriel fort. Si l'on veut hberger tous nos services de manire
indpendante, il n'est toutefois financirement pas judicieux d'acheter un serveur physique pour chacun. Il faut donc
penser utiliser des technologies de virtualisation, des conteneurs logiciels, ou du cloud.
Par exemple, Docker, grce sa vitesse, est particulirement adapt pour mener bien les nombreux dploiements.
IV-C - Erreurs viter
Des erreurs sont souvent commises par les dbutants. Nous allons en citer quelques-unes avec des suggestions
de solution.
IV-C-1 - Dcoupage
Dcouper une application monolithique en microservices n'est pas chose facile. Si l'application est mal dcoupe et
que les microservices ne sont pas bien modliss, cela peut crer beaucoup de problmes, notamment de couplage.
Par exemple, dans le cas o nous avons ds le dbut de nombreux services, cela peut engendrer des difficults
de dploiement.
Maladroitement, certaines quipes de dveloppement dbutantes en microservices dcoupent et redcoupent

lapplication en services jusqu'au point o chaque mthode est isole dans un nanoservice . Dans ce cas, les
rsultats des tests seront mauvais. Les changes entre ces nanoservices seront extrmement complexes, donc
difficiles comprendre et surveiller, les performances seront mauvaises et le nombre de serveurs ncessaires
sera important. Finalement, les inconvnients finissent par surpasser les avantages. Plus les services sont dcoups
finement, plus le systme sera lent. Enfin, la multiplication trop importante des services finit par rendre trs difficile
la surveillance du systme.
Il y a donc un quilibre trouver dans le dcoupage, de manire obtenir une granularit optimale. Nous pensons
qu'il faut la fois s'assurer qu'aucun service ne soit trop grand au point de ncessiter une quipe d'une dizaine de
personnes pour sa maintenance, et que chaque service corresponde bien une fonctionnalit mtier diffrente des
autres.
IV-C-2 - Monitoring
Pouvoir observer le comportement de chaque service est trs important (consommation de donnes, appels rseau,
erreurs, etc.). Chose qui peut s'avrer trs facile quand le systme ne compte que quelques services, mais quand
les services se multiplient et les connexions entre eux galement, il devient trs difficile de tout superviser.
-7-
Pour superviser ces services, il faut utiliser des logs ; pour localiser un log, l'quipe doit vrifier chaque microservice,
mais cela peut vite s'avrer trs compliqu quand le systme compte de nombreux microservices. Il faut aussi penser
localiser les erreurs en cas de dfaillance du systme.
Une des solutions est d'avoir un systme de logs centralis qui permet de voir de quel service vient un log. De cette
faon l'quipe peut savoir d'o viennent les erreurs et de les rgler dans les plus brefs dlais.
IV-C-3 - Difficult de la dfinition des microservices
Il peut arriver que les tests d'intgration se passent mal cause du manque de communication entre les personnes
ayant dvelopp les modules. Ce n'est pas un problme propre aux microservices, mais la multiplication des
modules, et le fait qu'il existe des frontires avec les fonctions mtier. On peut demander l'quipe crant le
microservice de crer des stubs (dans le cas o une bibliothque cliente a galement t dveloppe), mais cela ne
marchera pas si les technologies utilises sont trop htrognes. On pourrait aussi demander l'quipe de faire une
sorte de service stub, rpondant la mme API que le microservice, mais qui envoie des donnes factices.
Les tests doivent tre crs par l'quipe crivant le microservice puisqu'il doit s'agir d'un projet indpendant, car si
une autre quipe met en place les tests, le risque de se tromper est grand. On peut crer des mocks pour simuler
l'existence d'un microservice, mais il faut bien sr vrifier qu'il est bien appel par les clients. Pour que ces tests soient
utilisables par tous, on peut imaginer dvelopper un serveur de mocks avec une API similaire au service. Celui-ci
serait ensuite lanc par les clients lors des tests.
Cette mthode a l'avantage de pouvoir tre appele par n'importe qui, mais cela risque d'tre trop lent en pratique si
l'on doit l'utiliser chaque test unitaire, cause des appels rseau (mme vers la mme machine) qu'elle provoque.
V - Du monolithique aux microservices
Amazon et Netflix sont des entreprises parmi d'autres qui ont transform leurs applications monolithiques en des
applications en architecture microservice. Passer d'une application monolithique aux microservices est ainsi la
manire la plus recommande de mettre en place des microservices, certains allant jusqu' dire que c'est la seule
manire correcte.
L'ide est de prendre une application existante, de taille considrable, et de la dcouper progressivement en
diffrents services. On peut galement ajouter des nouvelles fonctionnalits en dveloppant de nouveaux services
si ncessaire.
Une application monolithique est relativement simple dcouper en microservices compar d'autres changements
dans une architecture. Cette approche a l'avantage de ne pas attendre qu'une application soit trop grande pour
pouvoir profiter des bnfices des microservices. La migration peut se faire de manire relativement simple par
rapport un autre changement d'architecture.
Cette option est utile quand le volume de code en question est tel qu'il devient un obstacle sa maintenance et
son dploiement rapide. Passer une application en microservices peut galement tre intressant dans le cas o
le temps entre chaque dploiement est trop long.
Il est souvent ncessaire de dcouper l'application progressivement, afin d'atteindre un bon dcoupage et de
permettre une adoption progressive des microservices. Ceci implique que les bnfices seront eux aussi progressifs.
Il faut galement penser aux changements oprer ct organisation et habitudes des quipes ; tout ceci peut
prendre du temps avant d'tre oprationnel.
Cette option permet aux diffrentes parties d'une entreprise de communiquer entre elles facilement, en partant du
principe qu'elles utilisent toutes des microservices. Il est important de se souvenir de ce qui a pouss l'architecte
utiliser l'architecture actuelle avant d'en changer, pour ne pas risquer de finir avec une application qui ne rpond
plus aux besoins des utilisateurs.
-8-
VI - Les microservices pour une nouvelle application
Les microservices peuvent aussi tre utiliss dans une nouvelle application. Des questions doivent cependant tre
poses.
Utiliser directement les microservices demande en effet d'avoir une bonne connaissance mtier du client afin
de pouvoir effectuer un dcoupage adquat. Cela demande en outre du temps, ce qui risque de ralentir les
dveloppements, alors que la plupart des bnfices ne seront pas visibles immdiatement.
Nous pouvons donc commencer par faire une application monolithique, qui sera par la suite dcoupe une fois
devenue trop grande.
VII - Conclusion
Les microservices permettent une organisation dcentralise, en petites quipes, fonctionnant indpendamment les
unes des autres, et permettant donc d'viter la plupart des gros problmes que peuvent rencontrer les projets de
taille importante.
Il faut bien prendre en compte les contraintes des microservices afin de pouvoir faire un bon choix. Les microservices
sont naturellement adapts aux applications (qui peuvent tre facilement dployes par le client) de taille importante,
et qui seront rgulirement mises jour. Il ne faut pas oublier que les microservices sont une architecture distribue
et que pour accder la partie mtier de l'application, il est ncessaire d'tre reli d'une manire ou d'une autre au
rseau contenant les microservices ncessaires l'utilisation de l'application.
On peut essayer de reproduire l'organisation des microservices dans d'autres types d'applications. Cependant, ce
n'est pas sans risque. En effet, cela demande plus de rigueur de la part des dveloppeurs ; il devient plus difficile
d'assurer l'indpendance de ses diffrentes parties sans oublier de prvoir la capacit de les dployer rgulirement.
-9-

Micro Services

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Micro Services

Hochgeladen von

Copyright:

Verfügbare Formate

Tutoriel pour apprendre sous quelles

conditions utiliser les microservices

Par Cherifa GHERSI AMARZOURGUI

Date de publication : 25 octobre 2017

II - Une volution des SOA ?

le fournisseur de service : acteur responsable du dveloppement du service, de son dploiement, de son

II-A-1 - Les caractristiques

Concentr sur une seule fonctionnalit

Dploiements individuels des microservices

Constitution d'un ou plusieurs processus

Un microservice, une base de donnes

La taille des microservices

III - Avantages des microservices

IV-B - Hbergement peu coteux

IV-C - Erreurs viter

Maladroitement, certaines quipes de dveloppement dbutantes en microservices dcoupent et redcoupent

IV-C-3 - Difficult de la dfinition des microservices

V - Du monolithique aux microservices

VI - Les microservices pour une nouvelle application

Das könnte Ihnen auch gefallen