conference microservices101 - 1ere partie
TRANSCRIPT
@gboissinot
10110 Février 2015
MicroServicesPrincipes & Enjeux
Automatisation(build, test, deploy)
Les Microservices favorisent le découpage de son système d’information en de petites unités métiers indépendantes et autonomes
« Fine-grained architecture »
UI 1Cod
e
ExportCode
PromotionCode
Application 1
UI 2Code
ReportingCode
Search EngineCode
Application 2
BDStore
RemoteServices BD Search &
Reporting
ImportCode
UI 1Code
Import / Export/
PromotionService
UI 2Code
ReportingService
Search EngineService
BDStore
RemoteServices
Datafor Reporting
DataFor Search
Focalisé minutieusement sur une et une seule responsabilité
Possédant un contexte d’exécution séparé (propre machine, propre processus, propre container, etc)
Communique à travers une interface uniforme
Capable d’être déployé indépendamment et de manière automatisé
Utilise un système d’inscription et de désinscription du réseau de Microservices
« Gather together those things thatchange for the same reason, and separate those things that change for different reasons »
Chaque service est une application métier autonome
Extension du pattern Single ResponsabilityPattern (SPR) au système d’information
La liberté des Microservices permet de réagir et de prendre des décisions plus rapidement à des changements inévitables (fonctionnels, techniques, organisationnels, etc)
Responsive
Elastic Resilient
Message-driven
Reactive Manifesto Pattern
Service 1« Python »
DocumentDatabase
Service 2Clojure
GraphDatabase
Service 3Java
SQLDatabase
Attention: Trouver le bon compromis entre l’autonomie des équipes (avec la flexibilité du choix) et le besoin de standardisation
Service 1C++
Service 2Python
Service 3Java
On crée des équipes pluridisciplinaires co-localisés orientées « Feature Métier »
Build & Run
Build & Run
Build & Run
New Service
Les architectures Microservices accélèrent l’innovation
Implication des Ops dans le métier
Adapté aux nouvelles organisations Client / Fournisseur
(Cloud, Infrastructure 2.0)
Application de la loi de Conway
MicroServices« Collaboration »
IMPL PUBLICAPI
Service
Une bonne API• Agnostique à un
langage• Porte la logique
d’intégration
Votre API est votre contrat en regroupant l’ensemble des opérations exportables pour vos consommateurs. Elle doit évoluer indépendamment de votre code
?
De nombreux protocoles et APId’intégration:RMIJAX-RPCJAX-WSJMSSOAP/HTTPREST/HTTPAMQetc
Trouver la communication la plus simple possible!
Dans le cas d’une base de données mutualisée, l’évolution des services suit l’évolution du schéma de base, les services sont fortement couplés.
SharedDatabase
T_CODE_PAYS
Duplication de l’information (de la donnée) dans chaque service
Gestion de la donnée à travers du code ou du paramétrage (fichier de conf, etc)
Encapsulation dans un service dédié
Complex Integration System(Encapsulate Logic)
Un bus d’intégration avec de la logique (routage, transformation, etc) fournit de l’intelligence dans la communication ce qui introduit une forme de couplage
API A API B
Protocole ATechnologie A
Format de données A
Protocole BTechnologie BFormat de données B
L’intégration doit être simple et favoriser le faible couplage des services
Synchrone ou
Asynchrone
Pas d’intelligence
1) Request / Response (synchrone ou asynchrone)
2) Event Based (asynchrone)
Service 1
Service 1
Service 2
Service 2
Event
subscribespublishes
Conçu pour cacher les appels distants
Diminue l’interdépendance des services en raison du partage d’un contrat
Fragile car on doit livrer un nouveau contrat à chaque changement
La fiabilité du réseau et le coût du marshallingsont à prendre en compte
On connaît les fonctionnalités mais on abstrait la localisation des services
La sémantique des messages pilotent le traitement des opérations
Des clients tolérants aux changements
Découplé temporellement & Physiquement
« Idenfiable Resources »
« Uniform interface »
« Stateless conversation »
« Resource representations »
« Hypermedia (HATEOS) »
Exploitation des méthodes HTTP (GET, POST, PUT, DELETE, HEAD, PATCH, OPTIONS)
Facile à consommer avec tous les langages
Plusieurs solutions pour la gestion des versions
Dans les communications modernes, REST/HTTP tend à remplacer les autres technologies d’intégration comme SOAP/HTTP
HTTPMETHOD
Resourcenames
+Uniform
interfaces
Les réponses REST contiennent les liens dont on a besoin
Les clients interagissent par « hypermedia »
Pas de connaissance préétablie de comment interagir avec le serveur
Le concept de HATEOS est unique. Cela permet au serveur d’évoluer fonctionnellement de manière indépendante des clients
On publie des événements
On souscrit à la réception d’événements
A chaque changement, un événement est envoyé
Les Microservices publient des événements en cas de changement d’état
Les autres Microservices souscrivent aux événements publiés• Synchronisation de la donnée répliquée• Maintient de la consistance entre plusieurs
systèmes
L’utilisation d’événements au niveau applicatif permet de garder la synchronisation des données répliquées et la consistance des données entre plusieurs systèmes
MicroServices« Chez les géants
du Web »
Compréhension du bénéfice d’avoir des équipes autonomes gérant tout le cycle de vie des produits
(conception, implémentation, déploiement)
Création d’outils pour faciliter l’indépendance et l’autonomie des équipes• Amazon Web Services• Suite d’outils Netflix (Hystrix, Eureka, etc)
Utilisation massive du PaaS (Cloud)A
Librairie contrôlant la collaboration entre les différents services pour offrir une grande tolérance à la latence et à l’échec
Isole l’accès et permet d’éviter « the failurecascade » en offrant des solutions de repli (fallback)
A
MicroservicesComment découper?
Shared Library
Modules
Les architectures Microservices peuvent être combinées avec d’autres techniques de décomposition.
Service Service Service
Library
Module A v1
Module A v2
Module B
Uniquement les librairies dynamiques évitent d’avoir à redéployer tous le processus en cas
de changement
Ne pas hésiter à dupliquer du code à travers plusieurs services
Essayer de se limiter à l’usage de librairies techniquesLe principe « DRY » ne doit être respecté qu’au sein d’un service
Erlang propose en natif sa notion de modules
Java avec OSGI n’a pas marché en raison de sa mauvaise intégration au
langage
En dehors de Erlang, l’implémentation des modules ne permet pas de bénéficier de tous les avantages des Microservices
« A Bounded Context is a specific responsabilityenforced by explicit boundaries »
On regroupe en bloc fonctionnel cohérent
Favorise le faible coupage et la forte cohésion
On évite d’avoir du code anémique
On garde la logique au sein du service
Toujours penser au service de plus haut niveau, puis affiner uniquement
si nécessaire ensuite
PackagingService
Metadata Repo Service
ImportService
ExportService
PromotionService
CompatibilityCheckerService
ReportingService Aucune interactions
entre les services de plus niveau
BOMService
Au début d’un projet, on ne connaît pas tout le scope du projet (le domaine change au fur et à mesure)
On a tendance à créer un Microservices à chaque nouveau besoin
Découper trop tôt en Microservices peut empêcher d’avoir une cohérence globale
Il est plus facile de décomposer en Microservicesune base de code existante que de partir de Zéro
On écrit des API qui répondent à des besoins réels et pas à des besoins futurs non idientifiés
On écrit des API qui est plus propice à l’extension qu’à la modification
On limite le nombre de Microservices et on n’hésite pas à faire du code jetable
On prend le temps sur la conception de la modélisation de la donnée échangée
MicroservicesSi on part d’un existant?
Un « seam » est un bloc de code indépendant
Ne pas hésiter à s’aider du découpage en package
Chaque « seam » va délimiter la frontière de son service
Trouver le bon découpage nécessite de comprendre le fonctionnel et le métier des différentes applications / services par les utilisateurs
NewService
GlueCode Monolith
On découpe toujours d’abord les données pour éviter de collaborer par le système de persistance
ImportCode
MonolithicSchema
Monolithic Service
PromotionCode
ImportCode
ImportSchema
PromotionCode
Promotion
Schema
ImportService
ImportSchema
PromotionService
Promotion
Schema
Monolithic Service
1 2 3
MicroServices« Les points d’attention »
Un nouveau langage ou une nouvelle technologie
à chaque service
Communication inter-service
Des systèmes de compensation avec des cas d’utilisation transverses
entre les services
Overhead
Latence
Fiabilité
L’infrastructure d’une architecture Microservices prend encore plus d’importance.Les NoOps n’existent pas. Au contraire, le rôle des opérationnels est renforcé
<person><firstname>Gregory<firstname><lastname>Boissinot<lastname>
</person>
<person><firstname>Gregory<firstname><lastname>Boissinot<lastname><twitterid>gboissinot</twitterid>
</person>
Règles: - Soyer conservateur dans la production de vos contrats- Soyer flexible dans ce que vous accepter en lecture- Utiliser une sémantique de version comme MAJOR.MINOR.PATCH
V1.0.0
V1.1.0
service
v1
Client 1 Client 2
service
v1
Client 1 Client 2
service
Client 1 Client 2
v2 v2
temps
Release 1 Release 2 Release 3
MicroServices« Pré requis DevOps »
On prend en considération la mixité technologique au niveau CI
On automatise la construction (CI) et le déploiement (CD) de chaque service
On doit assurer une certaine cohérence dans la livraison logicielle
On doit fournir un unique point d’administration
Host
Service
Host
Service
Host
Service
Host
Service
Avec un service par host, on évite les effets de bord en s’assurant que chaque service s’exécute en isolation avec ses prérequis technologiques
L’approche de la virtualisation est intéressante mais elle a coût
Utilisation ou création d’images
On peut « povisionner » l’image pour les besoins (Chef, Puppet, Ansible)
On voudrait idéalement exécuter chaque service dans une VM séparée (chaque service apporte son environnement)
L’approche de la virtualisation est intéressante mais elle a coût
Processus de création d’une image assez long
Les images sont souvent volumineuses(ex: > 20Go)
Le démarrage d’une VM peut prendre plusieurs minutes
Les hyperviseurs (comme KVM, Xen, etc) sont basés sur l’émulation d’infrastructure. C’est coûteux en terme de prérequis.L’approche Container propose une approche lightweight
Host
Container
Service
Container
Service
Container
Service
Container
Service
Les Containers sont rapides à provisionner
MicroServices« Pourquoi Docker ? »
L’approche de la virtualisation est intéressante mais elle a coût
Plateforme construite sur des containers Unix LXC
On crée et on déploie des applications comme des images dans le monde de la virtualisation
Facilite le provisioning de chaque service
S’appuie sur une registry d’images Docker
Une intégration dans les principaux outils de l’usine logicielle (Jenkins, Artifactory Pro, DockerHub, etc)
CoreOs (un Linux avec des services Docker)
Gestion de plusieurs containers (kubernetes, CoreOs’s cluster, etc)
Des outils (CI)CD
Et la SOA?
L’enjeu initial du SOA• Découper une application monolithique en
services (favorisant la réutilisabilité)• Focalisé sur l’intégration en lieu et place du
couplage des composants
Ce qui a généralement manqué• Abstrait jusqu’à la mise en production• Difficile à changer (ESB pattern)• Manque de consensus de faire du SOA
correctement
Conclusion
Ne cédez pas à toutes les possibilités offertesSurveiller, surveiller, … votre production!
L’enjeu est toujours de trouver le bon niveau de granularité
Déporte une certaine complexité au niveau de l’intégration et donc du déploiement
Nécessite d’avoir des cas d’usage qui s’y prêtent et d’avoir des équipes « produit » compétentes pour sa mise en place
Temps
# de services