name: title layout: true class: center, middle, inverse --- name: normal layout: true class: center, middle, noinverse --- template: title #Microservices .footnote[Matthieu Jacquot .red[@_err0r500]] --- template: normal Les grands principes de programmation ne s'envolent pas avec les microservices --- Le but d'une __bonne architecture__ n'est pas de trouver une solution définitive mais de __permettre les évolutions progressives__ ??? - evolutionary architecture (Neal Ford) --- template: title ## Unix philosophy --- template: normal > Write programs that do one thing and do it well. > > Write programs to work together. > > Write programs to handle text streams, because that is a universal interface. __Douglas McIlroy (1978)__ --- ### Ancien _vs_ Nouveau contexte -- programmes (ls, cp, grep) -- -> services "de base" -- \+ shell scripts -- -> services "métier" -- \+ text stream -- -> HTTP -- \+ OS -- -> Data plane -- _________________ = logiciel --- template: title ## Monolithe vs Microservices vs Monolithe distribué --- ### Monolithe -- _ ( Clean Architecture, Architecture Hexagonale, Ports & Adapters )_ -- Séparation stricte des niveaux d'abstraction et des responsabilités -- Inversion of Control (dépendance et abstraction pointent dans la même direction) ??? IoC : on peut changer d'implémentation sans toucher au code métier -- __... sinon__ -- __monolithe "fragile"__ --- ### Système distribué -- _( microservices )_ -- Séparation stricte des niveaux d'abstraction et des responsabilités -- Inversion of Control (dépendance et abstraction pointent dans la même direction) -- :-) -- __... sinon__ -- __"monolithe distribué"__ ??? monolithe distribué : le pire des 2 mondes --- template: title ## Ces grands principes restent avec les microservices -- En fait, ils deviennent même vitaux : -- c'est le contexte & l'implémentation qui changent --- ### Séparation des niveaux d'abstraction application vs data plane -- ### Inversion of Control abstraction par le network --- template: title ## A quoi reconnait-on une architecture microservices ? --- template: normal ### chaque service -- peut être déployé indépendamment -- peut utiliser le langage qu'il souhaite -- est assez petit pour être recodé from scratch sans crainte -- ne fait qu'une seule chose et la fait bien ??? n'importe quel langage : faire un choix en fonction du probleme, du moment, de la team --- ### le logiciel -- est pensé pour la résilience -- et les évolutions graduelles -- ( anti-fragile ) ??? résilience on mutualise downstream on ne partage pas de code inter services --- template: title ## service "de base" vs service "métier" -- opposés et complémentaires --- ### Un service de base -- n'a pas a connaitre son usage -- il fait son job, sans se soucier du but dans lequel il est utilisé -- ex : `grep` -- , accès à un datastore particulier --- ### Un service métier -- ne se pose aucune question sur les outils qu'il utilise -- il considère qu'ils respectent leur contrat, -- et les orchestre en ne se souciant __que__ de la finalité -- ex : réalisation d'une user-story ??? - outils : services de base --- template: title ## Inversion of Control -- Abstraction par le network --- ### Les moyens -- paramétrisation des "baseURL" -- API Gateway -- Service Mesh avec L7 load-balancer ??? - baseURL : protocol + domain + port --- ### En bonus -- canary release -- A/B testing -- dark launch & trafic observation ??? en pouvant faire pointer vers de nouveaux services de base, on peut changer l'implémentation (IoC) --- template: title ## Distributed Systems fallacies -- tout va bien se passer --- ### The network is reliable -- .red[ça va drop] -- .red[ça va corrompre] -- retries -- dead letter queue -- ??? flooding upstream attention au "poison message" --- ### Latency is zero -- .red[ sur la même machine, sur 2 DC différents : ça ne prend pas le même temps !] -- .red[ un service peut mettre _longtemps_ à répondre ] -- low-level matters -- circuit-breaking -- back pressure -- réponse async ??? back pressure : upstream tells downstream to stop sending him data --- ### Bandwidth is infinite -- .red[si tous le services broadcastent leurs messages, vous pouvez flooder le network] -- calls directs --- ### The network is secure -- .red[n'importe quel service peut être compromis] -- .red[le traffic ne sort _vraiment jamais_ du LAN ?] -- on opère toujours comme s'il passait par Internet ! -- _zero-trust network :_ -- mTLS inter-services -- service-to-service network policies -- __oubliez la défense en périmètre !__ --- ### Topology doesn't change -- .red[des services tombent et réaparaissent tout le temps] -- .red[les IPs ne sont pas fixes] -- Service discovery ??? - vous ne pointez pas vers une instance mais vers n instances healthy --- ### There is one administrator -- .red[plusieurs personnes peuvent modifier votre network] -- conf centralisée -- abstraction de ce qui se passe derriere l'API d'un service --- ### Transport cost is zero -- .red[le network fait partie intégrante de votre logiciel] -- il va falloir le gérer ??? aussi : chaque appel de service nécessite (dé)sérialization (cout niveau perf) --- ### The network is homogeneous -- .red[le nombre de hops peut varier d'une requête à l'autre] -- .red[les bottlenecks existent] -- tracing distribué ??? vous faites du many-to-many : la latence pour une même requete peut varier drastiquement suivant le chemin qu'elle prend observabilité de l'hostname : savoir quelle VM à géré, tracer la requete distributed tracing : hostname dans l'instrumentation --- template: title ## Séparation stricte des niveaux d'abstraction et des responsabilités -- data plane vs application --- ## Responsabilités du data plane -- service discovery -- retries -- circuit-breaking -- fault-injection (optionnel) --- ## Responsabilités d'une application -- tout ce qu'il fait habituellement dans un monolithe -- ### mais en plus, il -- _permet les retries_ : idempotent -- _simplifie la logique_ : CQRS -- _l'évolutibilité_ : backward & forward compatible -- _la communication_ : politique de déprécation --- template: title ## n++ instances -- sur n++ machines --- ### Tooling -- La survie passe par l'automatisation (et le versionning) de tout ce qui peut l'être -- Trouver les outils les plus simples permettant de faire le travail sans customization ??? iac : terraform, k8s --- ### Gestion des sources -- multi-repo -- trunk-based developpement ??? - multi-repo : simplifcation des pipelines de CI, complexifie le partage de code -> c'est ce que l'on veut ! - multi-repo : le point de contact entre votre code et votre stack, c'est l'artefact repository - trunk-based : une branche == un mec, 1 jour max -> PR, code-review doivent être très rapides - trunk-based : si vous pensez que votre projet est trop gros pour cela, c'est que ce n'est pas un microservice - artefact repository : docker registry, npm --- template: title ## Sécurité --- Zero-trust networks -- Container image scanning -- distroless base images -- Host security ??? - sur k8s : Security contexts --- template: title ## Est-ce que cela marche ? -- sur ma machine, oui ! --- Tout les éléments, ___data plane & applications___, participent au résultat final -- ### #devops ??? Devops & cloud-native deviennent obligatoires --- ## En amont --- ### CI/CD pour tous ! -- Intégration : création d'une unité de déploiement : artefact auto-suffisants -- Déploiement : run d'un artefact dans le data plane -- Release : routing du traffic vers un service --- ## En aval --- Comment construire un logiciel stable sur une base instable -- ___"everything fails all the time"___ (machine, composants, network, break API) --- ### Mesurer -- OS et Applications exposent des metrics (observabilité) ??? OS des VMs --- ### Détecter -- monitoring des machines & applications --- ### Alerter basé sur le monitoring -- ex : detection d'anomalies via ratios de requêtes inter-services ??? un service A appelle B ou C ( suivant valeur param ) : reqA == reqB + reqC --- ### Debuger -- ( y compris les performances ) -- Distributed tracing --- ### Auditer -- Logging centralisé -- sinon, un grep dans les logs de 50 machines ? --- template: title ## Qu'est-ce qui se passe si ... ? -- A votre avis ? -- Qu'est-ce qui pourrait faire que cela arrive ? -- On a qu'à essayer ! ### chaos-engineering --- template: title ## Questions ? .footnote[Matthieu Jacquot .red[@_err0r500]]