meetup microservice

Prsentation PowerPoint

MicroservicesREXsur larchitectureMicroservices

ce meetup restera assez ouvert, il y aura :des REXsessions de discutions sur diffrents.1

SommaireIntroductionDu dveloppement la productionLe bilan

SommaireIntroductionDu dveloppement la productionLe bilan

IntroductionQuest ce que larchitecture Microservices ?Le contexte

4

Architecture MicroservicesTransformation Lean de larchitecture

Le terme lean ( svelte) sert qualifier une thorie de gestion de la production qui se concentre sur la gestion sans gaspillage ou encore gestion au plus juste4.

Le lean trouve ses sources au Japon dans le systme de production de Toyota ou

L'cole de philosophie du lean est marque par la recherche de la performance (en matire de productivit, de qualit, de dlais, et enfin de cots)5

Architecture Microservices

Petit

Autonome

Fait une chose et le fait bien

Vision Business

la granuarit du service est celle dune fonctionnalit lmentaire, au sens mtier du terme. (ex: mtier interne identifier de la musique, du coup on a un microservice didentification de musique)6

Architecture MicroservicesCode sous contrle

Interface simple

Interface expressive

Puisque Microservice petit => le code est plus facilement gard sous contrlePlus facile de prendre en compte tout les cas (success + error)

Les interface dfinisse un contrat

Son interface doit tre suffisamment simple et expressive pour quiconque souhaitant lutiliser. (ex swager)7

Architecture MicroservicesCouplage faible

Groupe de microservices

Dans la mesure du possible, les services doivent tre faiblement coupls entre eux. Il y a aura forcment des groupes de microservices et ces groupes doivent ne avoir le moins possible et doivent tre le plus spar (moins de microservices en commun)8

Architecture MicroservicesSandbox

Pas de technologie en particulier

Microservices sandbox => un service dispose de son propre contexte dexcution => ce qui facilite sa mise jour.

pas de technologique a utiliser en particulier la base (langage, framework) ni mme larchitecture applicative mais il y a quand mme des pattern qui apparaissentEx: nodejs pour le backend des site web et python pour le reste

les services doivent tre inter-oprables

9

Architecture Microservices

10

Architecture MicroservicesDesign

Un microservice doit pouvoir tre :ConstruitTestDploy

de manire totalement isole des autres services 11

Pourquoi lesmicroservices

Module taille humaine

Sous estimation des moins

Complexit

Architecture monolithique (-) :Quand la quantit de code augmente, le code devient de plus en plus complexePlus le projet volue, plus il y a des interactions entre les diffrentes briquesMultiplication des effet de bord (ex: site intranet, les mails taient bloqus, car ajout de code sans connaitre lensemble du projet)

Microservices (+):Contraindre la taille limite, mettre en place les cas particulier => permet davoir tout en tteLes interface sont mieux gres

12

Pourquoi lesmicroservicesLa scalabilit

Scalabilit

Monolithique -:Amliorer la scalabilit dun systme peut demander de modifier des lments importantPlus le projet est gros plus lintervention est risques et couteuses

Risque: Le systme est trs difficile faire voluer voir impossible.

Micro +:Plus facile scaler, plus cibl13

Modlisation dun microservice

Image de baseLa configurationLapplicationComposantsLe script de dmarrageParamtres de dmarrageInput

Input outputBoite noirConfiguration environnement Connecter les interfaces14

Le contexte

Parce que ctait coolAnticipation sur les besoin de scalabilitModule taille humaine (forcer )Raison de performance mais discuttable

15

Le livre

Site rajouter16

SommaireIntroductionDu dveloppement la productionLe bilan

Le dveloppementGithub FlowCration de la branche (feature, hotfix )

Le dveloppementGithub FlowCommits (dveloppements)

Le dveloppementGithub FlowOuverture de la pull request (Release candidate)

Le dveloppementGithub FlowRevue du code & discution

Le dveloppementGithub FlowDploiement de la release

Le dveloppementGithub FlowMerge de la release

Github FlowComment est utilis github chez traxair

Le dveloppement

editor.swagger.ioswagger.io

Swagger se veut tre un standard de description dapi

Pour crer un microservice rest avec swaggerFichier yaml 400 lignes +-Serverside fonction write read dbBootstrap:Test ct serveur quasiment rien crire (moins de 5 lignes)Libraire client Cre une lib de test (custom tool)Code ct serveur gnr sauf dbLien avec lapi gateway, peut exposer ce microservice en ayant le choix dexposer les entrypoint (droit au get mais pas au post), cach ou pas des attribut25

Le dveloppement

Gnration dun microservices / librairie via templateGnration de code OK Gestion action pre/postPb : manque lenregistration dans la ci, deploiement, repository dartifact 26

Le dveloppementDevBox

DevboxDocker ComposeMakefile

DevboxFicher composeService_X: image: registry.com/Service_X ports: - "443:443" volumes: - Service_X/app:/app - Service_X/Service_X.env:/Service_X.env command: dev

LoutillageContinuous Integration

Continuous Integration

Continuous IntegrationArchitecture

Continuous IntegrationQuest ce qui doit tre test ?

Relation dordre topologique sur composants connexes du graphe orient acyclique

Graphe avec un sens (A dpend de B) sans cycle (impossible davoir A -> B -> C -> A)Composant connexes, possibilit davoir des groupes indpendant (A -> B, C)Relation topologique cest pour pouvoir dfinir lordre dexecution afin de savoir quel artifact est le premier, permet de classer

Il y a des librairies et des microservices.Les librairies crent du doublage.Ex:Lib dcodeer de laudio cre du couplageLib Mettre des fichier sur des bucketsObliger de grer les ordres dans lesquels a tournent

Les microservices dpendent de container de baseIl y a un couplage au niveau docker33

Continuous IntegrationLes tests

Environnement isol et propreTest unitaireServiceEnd to endTemps moyen dun test 1 minute

End to end on test que les happy34

Continuous IntegrationLes tests

Emulation dun microservice (stub)

Grce swagger on peut gnrer des test de faon automatique, on peut directement tester des lien entre les microservices au niveau des test unitaireshttp-pretty (lib) catch les requetes hhtp et renvoient une rponse avec les donnes attendu

Rduire le nombre de test end-to-end

Aprs un test on build lartefact35

Continuous IntegrationLe build

Temps moyen dun buildLibrairie : 1 minuteMicroservice : 10 minutesImage de base : 20 minutes

Tout les test et builds sont paralllissnombre de lib : 40Nombre de microservice : rest: 12, message queue: 2036

Continuous IntegrationReporting

Continuous IntegrationCode ReviewQualit de code

50k lignes de codeComplexit moyenne par ligne 10/100La plupart du code est test plus 80 %38

ProductionLinfrastructure

ProductionLe dploiement

ScreenshotPas de vu big computer (explication du big computer)Tutum permet davoir un parc de serveur40

Tutum

Gestion de la configuration

Lorsquun conteneur dmarre en mode production, il va interroger :EtcdRecuprer des clef valeurLes mettre en variable denvrionnement42

Diffrents types de microservices

Rest haproxy pour la gestion des ports tcpMessage queue pas de relle gestion mise part avoir ladresse de la message queue

43

Rseau

Mobify http requests are hard (blog)Lors dune communication via le rseau par exemple HTTP, beaucoup de choses peuvent mal de passer comme :Timeout de la requeteLe serveur a plantUn cable a t sectionnLapi a une limitation du nombre de requeteDNS / mauvais contenu /

Le but est de prvoir comment viter un maximum cest erreur

Comment grer ce genre de problme:Avoir un systme qui log lerreur afin de la comprendreUn systme de retry qui stale sur le temps

Tcp keep alive a activ dans les lib et serviceFonctionnalit optionnelle qui se repose sur un systme denvoie de paquets rseau afin dviter que le lien soit cass

Retry pour certains services44

ProductionLe monitoringDatadog, monitoring as a serviceELK, centralisation des logs et traitement

Cest un des obstacle consquent mais on peut se dbrouiller quand il ny pas beaucoup de microservices

45

SommaireIntroductionDu dveloppement la productionLe bilan

46

Le bilanLes microservices, c'est bien, mais c'est difficile mettre en place (et a nous a ralenti).

Penser que tout fonctionne sans problme voir design for faillure : http://blog.octo.com/design-for-failure/

Quest ce quon a fait qui ntait pas bien:Trop de microservices au dbutTrop microOn a pas eu le temps de faire le montoring

On a du faire une ci robuste plus rapidement

Ce quon recommande Partir du monolithique puis dcouper petit petit (baby step)Commencer mettre en place tout les concepts parls prcdemmentMise en place dautomatisation

Faire des microservices force avoir un esprit plus continuous delivery car plus de dploiement.Force avoir des best practices rapidement.

On a fait des erreurs mais on reste content de ce quon a fait et a a finit par marcher malgrs des difficults.47