SlideShare uma empresa Scribd logo
1 de 76
@gboissinot	
  
101	
  
10	
  Février	
  2015	
  
Principes
&
Enjeux
EMERGENCE DES MICROSERVICES
Automa'sa'on	
  
(build,	
  test,	
  deploy)	
  
Consolidation d’expériences
MICROSERVICES
Les Microservices favorisent le découpage de
son système d’information en de petites unités
métiers indépendantes et autonomes
Technique de décomposition
«	
  Fine-­‐grained	
  architecture	
  »	
  
APPROCHE MONOLITHIQUE
UI	
  1	
  
Code	
  
Export	
  
Code	
  
PromoCon	
  
Code	
  
ApplicaCon	
  1	
  
UI	
  2	
  
Code	
  
ReporCng	
  
Code	
  
Search	
  Engine	
  
Code	
  
ApplicaCon	
  2	
  
BD	
  
Store	
  
Remote	
  
Services	
   BD	
  Search	
  &	
  
ReporCng	
  
Import	
  
Code	
  
ON APPLIQUE LE CUBE DE SCALABILITÉ
ARCHITECTURE MICROSERVICES
UI	
  1	
  
Code	
  
Import	
  /	
  
Export/	
  
PromoCon	
  
Service	
  
UI	
  2	
  
Code	
  
ReporCng	
  
Service	
  
Search	
  Engine	
  
Service	
  
BD	
  
Store	
  
Remote	
  
Services	
  
Data	
  
for	
  ReporCng	
  
Data	
  
For	
  Search	
  
Première approche
LES MICROSERVICES
Pas de définition formelle mais un
ensemble de caractéristiques
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ée
Utilise un système d’inscription et de désinscription du
réseau de Microservices
ORIENTÉ « CAPACITÉ MÉTIER »
«	
  Gather	
  together	
  those	
  things	
  that	
  
change	
  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 Responsability
Pattern (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)
AU SERVICE
D’UNE ARCHITECTURE AGILE
Réduit le coût du changement
Responsive	
  
Elas'c	
   Resilient	
  
Message	
  
-­‐driven	
  
Reac've	
  Manifesto	
  Pa?ern	
  
FLEXIBILITÉ TECHNOLOGIQUE
Service	
  1	
  
«	
  Python	
  »	
  
	
  
Document	
  
Database	
  
	
  
Service	
  2	
  
Clojure	
  
	
  
Graph	
  
Database	
  
	
  
Service	
  3	
  
Java	
  
	
  
SQL	
  
Database	
  
	
  
Attention: Trouver le bon compromis entre
l’autonomie des équipes (avec la flexibilité du
choix) et le besoin de standardisation
Absorption des nouveaux
besoins
FAVORISE LA MIGRATION VERS DES
ORGANISATIONS AGILES
Service	
  1	
  
C++	
  
Service	
  2	
  
Python	
  
Service	
  3	
  
Java	
  
On crée des équipes pluridisciplinaires co-
localisées orientées « Feature Métier »
Build	
  &	
  Run	
  
Build	
  &	
  Run	
  
Build	
  &	
  Run	
  
Autonomie et performance des équipes
COMPOSITION
COMPOSITION
FLEXIBILITÉ DE
REMPLACEMENT
New	
  	
  
Service	
  
Les architectures Microservices accélèrent
l’innovation
On diminue la résistance au « refactoring »
Implication des Ops dans le métier
Adapté aux nouvelles organisations
Client / Fournisseur
(Cloud, Infrastructure 2.0)
DES BÉNÉFICES OPÉRATIONNELS
Au service d’une infrastructure agile
LA SCALABILITÉ EN ACTION
Application de
la loi de Conway
DES BÉNÉFICES ORGANISATIONNELS
MicroServices
« Collaboration »
UNE INTERFACE DE COMMUNICATION
SOUS FORME DE CONTRAT D’API
IMPL	
   PUBLIC	
  
API	
  
Service	
  
Une	
  bonne	
  API	
  
•  AgnosCque	
  à	
  un	
  
langage	
  
•  Porte	
  la	
  logique	
  
d’intégraCon	
  
Votre API est votre contrat en regroupant
l’ensemble des opérations exportables pour vos
consommateurs.
Elle doit évoluer indépendamment de votre code
Un contrat dirigé par les attentes des
consommateurs
« ZONING DU SI»
?	
  
De	
  nombreux	
  
protocoles	
  et	
  API	
  
d’intégraCon:	
  
RMI	
  
JAX-­‐RPC	
  
JAX-­‐WS	
  
JMS	
  
SOAP/HTTP	
  
REST/HTTP	
  
AMQ	
  
etc	
  
Trouver	
  la	
  communicaCon	
  la	
  
plus	
  simple	
  possible!	
  
ON ÉVITE DE COLLABORER
PAR LA DONNÉE
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.
Shared	
  	
  
Database	
  
MAIS POUR LE PARTAGE DE
DONNÉES STATIQUES?
	
  	
  
T_CODE_PAYS	
  
DES SOLUTIONS À LA
GESTION DES DONNÉES
STATIQUES
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é
ON ÉVITE DE COLLABORER À
TRAVERS UN BUS D’INTÉGRATION
Complex	
  IntegraCon	
  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
ANALOGIE « TINKER TOY »
Des « endpoints » intelligents et des
communications simples
COLLABORATION
DES SERVICES ENTRE EUX
Trouver un modèle de collaboration
standard et efficace
API	
  A	
  
API	
  B	
  
Protocole	
  A	
  
Technologie	
  A	
  
Format	
  de	
  données	
  A	
  
Protocole	
  B	
  
Technologie	
  B	
  
Format	
  de	
  données	
  B	
  
L’intégration doit être simple et favoriser
le faible couplage des services
Synchrone	
  	
  
ou	
  	
  
Asynchrone	
  
Pas	
  
d’intelligence	
  
STYLES DE COLLABORATION
1) Request / Response (synchrone ou asynchrone)
2) Event Based (asynchrone)
Service	
  	
  
1	
  
Service	
  	
  
1	
  
Service	
  	
  
2	
  
Service	
  	
  
2	
  
Event	
  
subscribes	
  publishes	
  
LE REMOTING, STYLE INTRUSIF
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 marshalling
sont à prendre en compte
Une promesse de transparence
difficile à tenir
LE MESSAGING A LA
RESCOUSSE
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
L’EXISTENCE DE REST
« Identifiable Resources »
« Uniform interface »
« Stateless conversation »
« Resource representations »
« Hypermedia (HATEOS) »
Un style d’architecture respectant
un ensemble de contraintes
« REST OVER HTTP »
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
Une forme de Messaging
« UNIFORM INTERFACE »
REST OVER HTTP
Simplification d’accès
HTTP	
  
METHOD	
  
Resource	
  
names	
  
+	
  
Uniform	
  
interfaces	
  
HATEOAS – HYPERMEDIA AS THE
ENGINE OF APPLICATION STATE
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
Découple le client et le serveur
MODÈLE DE MATURITÉ DE
RICHARDSON
La maturité de la mise en œuvre de REST
« EVENT-BASED COMMUNICATION »
On publie des événements
On souscrit à la réception d’événements
A chaque changement, un événement est
envoyé
Utilisation d’un bus de messages
« EVENT-BASED ARCHITECTURE »
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
La meilleure solution
MicroServices
« Chez les géants
du Web »
DES CARACTÉRISTIQUES
COMMUNES
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
NETFLIX HYSTRIX
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 failure cascade »
en offrant des solutions de repli (fallback)
Au service de la
résilience globale
NETFLIX HYSTRIX
A
Microservices
Comment découper?
LES AUTRES TECHNIQUES
DE DÉCOMPOSITION
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	
  
SHARED LIBRARY
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
techniques
Le principe « DRY » ne doit être respecté qu’au sein
d’un service
Technique ou fonctionnel, favorise la
réutilisabilité
MODULES
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
On favorise le partage de code
S’APPUYER SUR LES
BOUNDED CONTEXT
« A Bounded Context is a specific responsability
enforced 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
PENSER
« COARSER-GRAINED »
Toujours penser au service de plus haut
niveau, puis affiner uniquement
si nécessaire ensuite
« COARSER-GRAINED »
Packaging	
  
Service	
  
Metadata	
  Repo	
  Service	
  
Import	
  
Service	
  
Export	
  
Service	
  
Promo'on	
  
Service	
  
Compa'bilityChecker	
  
Service	
  
Repor'ng	
  
Service	
  
Exemple
Aucune	
  interac'ons	
  
entre	
  les	
  services	
  de	
  
plus	
  niveau	
  
BOM	
  
Service	
  
ON ÉCRIT D’ABORD DU CODE
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 Microservices
une base de code existante que de partir de Zéro
On « refactore » ensuite
ON NE CÉDER PAS À LA TENTATION
On écrit des API qui répondent à des besoins réels et
pas à des besoins futurs non identifié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
Microservices
Si on part d’un existant?
ON TROUVE LES SEAMS
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
ON SE REND CONFORME AUX
ARCHITECTURES MICROSERVICES
New	
  
Service	
  
Glue	
  
Code	
  
Monolith	
  
DÉCOUPER EN SERVICES DEPUIS
UN SEUL SCHÉMA DE BASE
On découpe toujours d’abord les données pour
éviter de collaborer par le système de persistance
Import	
  
Code	
  
Monolithic	
  
Schema	
  
Monolithic	
  Service	
  
PromoCon	
  
Code	
  
Import	
  
Code	
  
Import	
  
Schema	
  
PromoCon	
  
Code	
  
Promo
Con	
  
Schema	
  
Import	
  
Service	
  
Import	
  
Schema	
  
PromoCon	
  
Service	
  
Promo
Con	
  
Schema	
  
Monolithic	
  Service	
  
1	
   2	
   3	
  
MicroServices
« Les points d’attention »
AJOUT DE COMPLEXITÉ
POUR LES DÉVELOPPEURS
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
L’ENJEU D’UNE
COMMUNICATION RÉSEAU
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é
CAS D’UNE COMMUNICATION EXTERNE
<person>	
  
	
  <firstname>Gregory<firstname>	
  
	
  <lastname>Boissinot<lastname>	
  
</person>	
  
<person>	
  
	
  <firstname>Gregory<firstname>	
  
	
  <lastname>Boissinot<lastname>	
  
	
  <twi?erid>gboissinot</twi?erid>	
  
</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	
  
« Tolerent Consumer & Conservative producer »
ON MIGRE RAPIDEMENT
service	
  
v1	
  
Client	
  1	
   Client	
  2	
  
service	
  
v1	
  
Client	
  1	
   Client	
  2	
  
service	
  
Client	
  1	
   Client	
  2	
  
v2	
   v2	
  
temps	
  
On conserve pas longtemps les anciennes
versions
Release	
  1	
   Release	
  2	
   Release	
  3	
  
MicroServices
« Pré requis DevOps »
« SELF CONTAINED
DEPLOYED MICROSERVICES »
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
1 SERVICE PAR « HOST »
L’isolation
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
LA VIRTUALISATION
Une solution pour éviter d’avoir
plusieurs machines physiques
L’approche de la virtualisation est intéressante mais
elle a coût
Utilisation ou création d’images
On peut « provisionner » 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)
LA VIRTUALISATION
Les problèmes
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 CONTAINERS
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 légère.
A la rescousse
Host	
  
UN SERVICE PAR CONTAINER
Solution idéale avec le bon degré d’isolation
Container	
  
Service	
  
Container	
  
Service	
  
Container	
  
Service	
  
Container	
  
Service	
  
Les Containers sont rapides à provisionner
MicroServices
« Pourquoi Docker ? »
PLATEFORME 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 registre d’images Docker
	
  
1 Micro Service : 1 système Unix
UN VASTE ÉCOSYSTÈME
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 cluster, etc)
Des outils (CI)CD
UN ÉCOSYSTÈME D’OUTILS
POUR FACILITER LA MISE EN
ŒUVRE TECHNIQUE
Et la SOA?
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
De bonnes idées mais un manque de maturité
Conclusion
MICROSERVICES
Ne cédez pas à toutes les possibilités offertes
Surveillez, surveillez, … votre production!
Synthèse
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
MICROSERVICES
Une stratégie à long terme
Temps	
  
#	
  de	
  services	
  

Mais conteúdo relacionado

Mais procurados

Architecture Réseau des clouds privés avec Hyper-V et System Center Virtual M...
Architecture Réseau des clouds privés avec Hyper-V et System Center Virtual M...Architecture Réseau des clouds privés avec Hyper-V et System Center Virtual M...
Architecture Réseau des clouds privés avec Hyper-V et System Center Virtual M...Microsoft Technet France
 
Implémenter son Cloud privé pour héberger ses machines virtuelles
Implémenter son Cloud privé pour héberger ses machines virtuellesImplémenter son Cloud privé pour héberger ses machines virtuelles
Implémenter son Cloud privé pour héberger ses machines virtuellesMicrosoft Décideurs IT
 
Windows Azure : Modèle hybride et réversibilité
Windows Azure : Modèle hybride et réversibilitéWindows Azure : Modèle hybride et réversibilité
Windows Azure : Modèle hybride et réversibilitéMicrosoft Technet France
 
Architectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythmeArchitectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythmeMicrosoft
 
SQL Azure Data Sync ou comment synchroniser vos données avec le Cloud ?
SQL Azure Data Sync ou comment synchroniser vos données avec le Cloud ?SQL Azure Data Sync ou comment synchroniser vos données avec le Cloud ?
SQL Azure Data Sync ou comment synchroniser vos données avec le Cloud ?Microsoft
 
Watchguard la solution de sécurité informatique Partenaire expert de référence
Watchguard la solution de sécurité informatique Partenaire expert de référenceWatchguard la solution de sécurité informatique Partenaire expert de référence
Watchguard la solution de sécurité informatique Partenaire expert de référencePROJECT SI
 
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private CloudLe Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private CloudMicrosoft Technet France
 
Sécuriser son projet Serverless
Sécuriser son projet ServerlessSécuriser son projet Serverless
Sécuriser son projet ServerlessManon PERNIN
 
Séminaire Sécurité Linagora mai 2009
Séminaire Sécurité Linagora mai 2009Séminaire Sécurité Linagora mai 2009
Séminaire Sécurité Linagora mai 2009LINAGORA
 
Introduction à la formation CERTIFICATE OF CLOUD SECURITY KNOWLEDGE / CCSK de...
Introduction à la formation CERTIFICATE OF CLOUD SECURITY KNOWLEDGE / CCSK de...Introduction à la formation CERTIFICATE OF CLOUD SECURITY KNOWLEDGE / CCSK de...
Introduction à la formation CERTIFICATE OF CLOUD SECURITY KNOWLEDGE / CCSK de...Tactika inc.
 
Implémenter de l’authentification forte pour vos environnements Cloud
Implémenter de l’authentification forte pour vos environnements CloudImplémenter de l’authentification forte pour vos environnements Cloud
Implémenter de l’authentification forte pour vos environnements CloudMicrosoft Décideurs IT
 
Tout ce que vous avez toujours voulu savoir sur Windows Azure Pack sans jamai...
Tout ce que vous avez toujours voulu savoir sur Windows Azure Pack sans jamai...Tout ce que vous avez toujours voulu savoir sur Windows Azure Pack sans jamai...
Tout ce que vous avez toujours voulu savoir sur Windows Azure Pack sans jamai...Microsoft Technet France
 
LinPKI EJBCA : une PKI open source en route vers la certification Critères Co...
LinPKI EJBCA : une PKI open source en route vers la certification Critères Co...LinPKI EJBCA : une PKI open source en route vers la certification Critères Co...
LinPKI EJBCA : une PKI open source en route vers la certification Critères Co...LINAGORA
 
DCS : La solution de Cloud Privé par Microsoft Services
DCS : La solution de Cloud Privé par Microsoft ServicesDCS : La solution de Cloud Privé par Microsoft Services
DCS : La solution de Cloud Privé par Microsoft ServicesMicrosoft Technet France
 
Projet Pki Etapes Clefs
Projet Pki   Etapes ClefsProjet Pki   Etapes Clefs
Projet Pki Etapes Clefsfabricemeillon
 
Concevoir votre infrastructure Cloud privés avec Hyper-V et System Center
Concevoir votre infrastructure Cloud privés avec Hyper-V et System Center Concevoir votre infrastructure Cloud privés avec Hyper-V et System Center
Concevoir votre infrastructure Cloud privés avec Hyper-V et System Center Microsoft Décideurs IT
 
[AzureCamp 24 Juin 2014] Interactions en "temps réel" pour les applications W...
[AzureCamp 24 Juin 2014] Interactions en "temps réel" pour les applications W...[AzureCamp 24 Juin 2014] Interactions en "temps réel" pour les applications W...
[AzureCamp 24 Juin 2014] Interactions en "temps réel" pour les applications W...Microsoft Technet France
 
LinShare : partage de fichiers sécurisé et coffre-fort électronique
LinShare : partage de fichiers sécurisé et coffre-fort électronique LinShare : partage de fichiers sécurisé et coffre-fort électronique
LinShare : partage de fichiers sécurisé et coffre-fort électronique LINAGORA
 

Mais procurados (20)

LinPKI
LinPKILinPKI
LinPKI
 
Architecture Réseau des clouds privés avec Hyper-V et System Center Virtual M...
Architecture Réseau des clouds privés avec Hyper-V et System Center Virtual M...Architecture Réseau des clouds privés avec Hyper-V et System Center Virtual M...
Architecture Réseau des clouds privés avec Hyper-V et System Center Virtual M...
 
Implémenter son Cloud privé pour héberger ses machines virtuelles
Implémenter son Cloud privé pour héberger ses machines virtuellesImplémenter son Cloud privé pour héberger ses machines virtuelles
Implémenter son Cloud privé pour héberger ses machines virtuelles
 
Windows Azure : Modèle hybride et réversibilité
Windows Azure : Modèle hybride et réversibilitéWindows Azure : Modèle hybride et réversibilité
Windows Azure : Modèle hybride et réversibilité
 
PKI par la Pratique
PKI par la PratiquePKI par la Pratique
PKI par la Pratique
 
Architectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythmeArchitectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythme
 
SQL Azure Data Sync ou comment synchroniser vos données avec le Cloud ?
SQL Azure Data Sync ou comment synchroniser vos données avec le Cloud ?SQL Azure Data Sync ou comment synchroniser vos données avec le Cloud ?
SQL Azure Data Sync ou comment synchroniser vos données avec le Cloud ?
 
Watchguard la solution de sécurité informatique Partenaire expert de référence
Watchguard la solution de sécurité informatique Partenaire expert de référenceWatchguard la solution de sécurité informatique Partenaire expert de référence
Watchguard la solution de sécurité informatique Partenaire expert de référence
 
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private CloudLe Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
 
Sécuriser son projet Serverless
Sécuriser son projet ServerlessSécuriser son projet Serverless
Sécuriser son projet Serverless
 
Séminaire Sécurité Linagora mai 2009
Séminaire Sécurité Linagora mai 2009Séminaire Sécurité Linagora mai 2009
Séminaire Sécurité Linagora mai 2009
 
Introduction à la formation CERTIFICATE OF CLOUD SECURITY KNOWLEDGE / CCSK de...
Introduction à la formation CERTIFICATE OF CLOUD SECURITY KNOWLEDGE / CCSK de...Introduction à la formation CERTIFICATE OF CLOUD SECURITY KNOWLEDGE / CCSK de...
Introduction à la formation CERTIFICATE OF CLOUD SECURITY KNOWLEDGE / CCSK de...
 
Implémenter de l’authentification forte pour vos environnements Cloud
Implémenter de l’authentification forte pour vos environnements CloudImplémenter de l’authentification forte pour vos environnements Cloud
Implémenter de l’authentification forte pour vos environnements Cloud
 
Tout ce que vous avez toujours voulu savoir sur Windows Azure Pack sans jamai...
Tout ce que vous avez toujours voulu savoir sur Windows Azure Pack sans jamai...Tout ce que vous avez toujours voulu savoir sur Windows Azure Pack sans jamai...
Tout ce que vous avez toujours voulu savoir sur Windows Azure Pack sans jamai...
 
LinPKI EJBCA : une PKI open source en route vers la certification Critères Co...
LinPKI EJBCA : une PKI open source en route vers la certification Critères Co...LinPKI EJBCA : une PKI open source en route vers la certification Critères Co...
LinPKI EJBCA : une PKI open source en route vers la certification Critères Co...
 
DCS : La solution de Cloud Privé par Microsoft Services
DCS : La solution de Cloud Privé par Microsoft ServicesDCS : La solution de Cloud Privé par Microsoft Services
DCS : La solution de Cloud Privé par Microsoft Services
 
Projet Pki Etapes Clefs
Projet Pki   Etapes ClefsProjet Pki   Etapes Clefs
Projet Pki Etapes Clefs
 
Concevoir votre infrastructure Cloud privés avec Hyper-V et System Center
Concevoir votre infrastructure Cloud privés avec Hyper-V et System Center Concevoir votre infrastructure Cloud privés avec Hyper-V et System Center
Concevoir votre infrastructure Cloud privés avec Hyper-V et System Center
 
[AzureCamp 24 Juin 2014] Interactions en "temps réel" pour les applications W...
[AzureCamp 24 Juin 2014] Interactions en "temps réel" pour les applications W...[AzureCamp 24 Juin 2014] Interactions en "temps réel" pour les applications W...
[AzureCamp 24 Juin 2014] Interactions en "temps réel" pour les applications W...
 
LinShare : partage de fichiers sécurisé et coffre-fort électronique
LinShare : partage de fichiers sécurisé et coffre-fort électronique LinShare : partage de fichiers sécurisé et coffre-fort électronique
LinShare : partage de fichiers sécurisé et coffre-fort électronique
 

Destaque

Paris Redis Meetup Introduction
Paris Redis Meetup IntroductionParis Redis Meetup Introduction
Paris Redis Meetup IntroductionGregory Boissinot
 
Micro-Service Architectures in E-Commerce environments with SPHERE.IO / comme...
Micro-Service Architectures in E-Commerce environments with SPHERE.IO / comme...Micro-Service Architectures in E-Commerce environments with SPHERE.IO / comme...
Micro-Service Architectures in E-Commerce environments with SPHERE.IO / comme...Dirk Hoerig
 
Patterns for building resilient and scalable microservices platform on AWS
Patterns for building resilient and scalable microservices platform on AWSPatterns for building resilient and scalable microservices platform on AWS
Patterns for building resilient and scalable microservices platform on AWSBoyan Dimitrov
 
Ecommerce : Conseils et solutions avec Google AdWords
Ecommerce : Conseils et solutions avec Google AdWordsEcommerce : Conseils et solutions avec Google AdWords
Ecommerce : Conseils et solutions avec Google AdWordsDamien Marchois
 
Backday Xebia : Découvrez Spring Boot sur un cas pratique
Backday Xebia : Découvrez Spring Boot sur un cas pratiqueBackday Xebia : Découvrez Spring Boot sur un cas pratique
Backday Xebia : Découvrez Spring Boot sur un cas pratiquePublicis Sapient Engineering
 
Fusion des régions : dossier spécial dans Juramag
Fusion des régions : dossier spécial dans JuramagFusion des régions : dossier spécial dans Juramag
Fusion des régions : dossier spécial dans JuramagDépartement du Jura
 
Chargé de mission pn amp et sports de nature
Chargé de mission pn  amp et sports de nature Chargé de mission pn  amp et sports de nature
Chargé de mission pn amp et sports de nature CREPS de Montpellier
 
Etude 50 nuances de numerique par le Motif
Etude 50 nuances de numerique par le MotifEtude 50 nuances de numerique par le Motif
Etude 50 nuances de numerique par le MotifVincent DEMULIERE
 
18 - F2000 - 2011 - Louis Armand - Villefranche
18 - F2000 - 2011 - Louis Armand - Villefranche18 - F2000 - 2011 - Louis Armand - Villefranche
18 - F2000 - 2011 - Louis Armand - VillefrancheCédric Frayssinet
 
Afegir so PowerPoint 2007
Afegir so PowerPoint 2007Afegir so PowerPoint 2007
Afegir so PowerPoint 2007silvia molera
 
WHERE MINIMAL ART MEETS FEMINIST ART
WHERE MINIMAL ART MEETS FEMINIST ARTWHERE MINIMAL ART MEETS FEMINIST ART
WHERE MINIMAL ART MEETS FEMINIST ARTALEXANDRA JULIA ERN
 
Baromètre Mobile Marketing Association France : Déc 2013 - infographie
Baromètre Mobile Marketing Association France : Déc 2013 - infographieBaromètre Mobile Marketing Association France : Déc 2013 - infographie
Baromètre Mobile Marketing Association France : Déc 2013 - infographiePhilippe Dumont
 
Presentación II MKT Intelligence - Christina Saksanian - Hedaz
Presentación II MKT Intelligence - Christina Saksanian - HedazPresentación II MKT Intelligence - Christina Saksanian - Hedaz
Presentación II MKT Intelligence - Christina Saksanian - HedazNeo Consulting
 
Presentation are sofer bis RHT 15.10.12
Presentation are sofer bis RHT 15.10.12Presentation are sofer bis RHT 15.10.12
Presentation are sofer bis RHT 15.10.12alain jeannot
 
Gamme Virage Lht
Gamme Virage LhtGamme Virage Lht
Gamme Virage Lhtvpp1512
 
Lesson 7 7 polygons
Lesson 7 7 polygonsLesson 7 7 polygons
Lesson 7 7 polygonsmlabuski
 
Imágenes de grecia
Imágenes de greciaImágenes de grecia
Imágenes de greciaNINES00
 
Présentation call on'u escp europe concours ernst&young
Présentation call on'u escp europe   concours ernst&youngPrésentation call on'u escp europe   concours ernst&young
Présentation call on'u escp europe concours ernst&youngsoazig27
 

Destaque (20)

Paris Redis Meetup Introduction
Paris Redis Meetup IntroductionParis Redis Meetup Introduction
Paris Redis Meetup Introduction
 
Micro-Service Architectures in E-Commerce environments with SPHERE.IO / comme...
Micro-Service Architectures in E-Commerce environments with SPHERE.IO / comme...Micro-Service Architectures in E-Commerce environments with SPHERE.IO / comme...
Micro-Service Architectures in E-Commerce environments with SPHERE.IO / comme...
 
Patterns for building resilient and scalable microservices platform on AWS
Patterns for building resilient and scalable microservices platform on AWSPatterns for building resilient and scalable microservices platform on AWS
Patterns for building resilient and scalable microservices platform on AWS
 
Ecommerce : Conseils et solutions avec Google AdWords
Ecommerce : Conseils et solutions avec Google AdWordsEcommerce : Conseils et solutions avec Google AdWords
Ecommerce : Conseils et solutions avec Google AdWords
 
Backday Xebia : Découvrez Spring Boot sur un cas pratique
Backday Xebia : Découvrez Spring Boot sur un cas pratiqueBackday Xebia : Découvrez Spring Boot sur un cas pratique
Backday Xebia : Découvrez Spring Boot sur un cas pratique
 
Fusion des régions : dossier spécial dans Juramag
Fusion des régions : dossier spécial dans JuramagFusion des régions : dossier spécial dans Juramag
Fusion des régions : dossier spécial dans Juramag
 
Chargé de mission pn amp et sports de nature
Chargé de mission pn  amp et sports de nature Chargé de mission pn  amp et sports de nature
Chargé de mission pn amp et sports de nature
 
Etude 50 nuances de numerique par le Motif
Etude 50 nuances de numerique par le MotifEtude 50 nuances de numerique par le Motif
Etude 50 nuances de numerique par le Motif
 
18 - F2000 - 2011 - Louis Armand - Villefranche
18 - F2000 - 2011 - Louis Armand - Villefranche18 - F2000 - 2011 - Louis Armand - Villefranche
18 - F2000 - 2011 - Louis Armand - Villefranche
 
Afegir so PowerPoint 2007
Afegir so PowerPoint 2007Afegir so PowerPoint 2007
Afegir so PowerPoint 2007
 
WHERE MINIMAL ART MEETS FEMINIST ART
WHERE MINIMAL ART MEETS FEMINIST ARTWHERE MINIMAL ART MEETS FEMINIST ART
WHERE MINIMAL ART MEETS FEMINIST ART
 
Baromètre Mobile Marketing Association France : Déc 2013 - infographie
Baromètre Mobile Marketing Association France : Déc 2013 - infographieBaromètre Mobile Marketing Association France : Déc 2013 - infographie
Baromètre Mobile Marketing Association France : Déc 2013 - infographie
 
Presentación II MKT Intelligence - Christina Saksanian - Hedaz
Presentación II MKT Intelligence - Christina Saksanian - HedazPresentación II MKT Intelligence - Christina Saksanian - Hedaz
Presentación II MKT Intelligence - Christina Saksanian - Hedaz
 
8 gl1
8 gl18 gl1
8 gl1
 
Belles photos2
Belles photos2Belles photos2
Belles photos2
 
Presentation are sofer bis RHT 15.10.12
Presentation are sofer bis RHT 15.10.12Presentation are sofer bis RHT 15.10.12
Presentation are sofer bis RHT 15.10.12
 
Gamme Virage Lht
Gamme Virage LhtGamme Virage Lht
Gamme Virage Lht
 
Lesson 7 7 polygons
Lesson 7 7 polygonsLesson 7 7 polygons
Lesson 7 7 polygons
 
Imágenes de grecia
Imágenes de greciaImágenes de grecia
Imágenes de grecia
 
Présentation call on'u escp europe concours ernst&young
Présentation call on'u escp europe   concours ernst&youngPrésentation call on'u escp europe   concours ernst&young
Présentation call on'u escp europe concours ernst&young
 

Semelhante a PZ_Microservices101_20150210

Architecture orientée service (SOA)
Architecture orientée service (SOA)Architecture orientée service (SOA)
Architecture orientée service (SOA)Klee Group
 
Cellenza dev test - azure service fabric - v1.0 - slideshare
Cellenza   dev test - azure service fabric - v1.0 - slideshareCellenza   dev test - azure service fabric - v1.0 - slideshare
Cellenza dev test - azure service fabric - v1.0 - slideshareRadoine Douhou
 
[DevTestday] Azure service fabric - Radoine Douhou
[DevTestday] Azure service fabric -  Radoine Douhou[DevTestday] Azure service fabric -  Radoine Douhou
[DevTestday] Azure service fabric - Radoine DouhouCellenza
 
Architectures orientées services
Architectures orientées servicesArchitectures orientées services
Architectures orientées servicesDonia Hammami
 
MS Days 2011 - Windows Azure
MS Days 2011 - Windows AzureMS Days 2011 - Windows Azure
MS Days 2011 - Windows AzureJason De Oliveira
 
L'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOpsL'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOpsGeorgeot Cédric
 
L’intégration, facteur clef de succès d’une transformation digitale
L’intégration, facteur clef de succès d’une transformation digitaleL’intégration, facteur clef de succès d’une transformation digitale
L’intégration, facteur clef de succès d’une transformation digitaleManon PERNIN
 
Architecture microservices avec docker
Architecture microservices avec dockerArchitecture microservices avec docker
Architecture microservices avec dockergcatt
 
eServices-Chp4: ESB
eServices-Chp4: ESBeServices-Chp4: ESB
eServices-Chp4: ESBLilia Sfaxi
 
Integration Summit 16 - Keynote Integration Trends
Integration Summit 16 - Keynote Integration TrendsIntegration Summit 16 - Keynote Integration Trends
Integration Summit 16 - Keynote Integration TrendsCellenza
 
Présentation evénement AWS - 13 oct 2015
Présentation evénement AWS  - 13 oct 2015 Présentation evénement AWS  - 13 oct 2015
Présentation evénement AWS - 13 oct 2015 ABC Systemes
 
Le design d'API avec Mulesoft
Le design d'API avec MulesoftLe design d'API avec Mulesoft
Le design d'API avec MulesoftSpikeeLabs
 
PARTAGE par RENATER avec Cloudwatt & Netixia
PARTAGE par RENATER avec Cloudwatt & NetixiaPARTAGE par RENATER avec Cloudwatt & Netixia
PARTAGE par RENATER avec Cloudwatt & NetixiaAntony Barroux
 
Transformer votre Cloud : est-ce si simple ? La réponse avec les solutions EM...
Transformer votre Cloud : est-ce si simple ? La réponse avec les solutions EM...Transformer votre Cloud : est-ce si simple ? La réponse avec les solutions EM...
Transformer votre Cloud : est-ce si simple ? La réponse avec les solutions EM...Microsoft Ideas
 
Azure Service Fabric pour les développeurs
Azure Service Fabric pour les développeursAzure Service Fabric pour les développeurs
Azure Service Fabric pour les développeursMicrosoft
 

Semelhante a PZ_Microservices101_20150210 (20)

ESB
ESBESB
ESB
 
Architecture orientée service (SOA)
Architecture orientée service (SOA)Architecture orientée service (SOA)
Architecture orientée service (SOA)
 
Cellenza dev test - azure service fabric - v1.0 - slideshare
Cellenza   dev test - azure service fabric - v1.0 - slideshareCellenza   dev test - azure service fabric - v1.0 - slideshare
Cellenza dev test - azure service fabric - v1.0 - slideshare
 
[DevTestday] Azure service fabric - Radoine Douhou
[DevTestday] Azure service fabric -  Radoine Douhou[DevTestday] Azure service fabric -  Radoine Douhou
[DevTestday] Azure service fabric - Radoine Douhou
 
Architectures orientées services
Architectures orientées servicesArchitectures orientées services
Architectures orientées services
 
MS Days 2011 - Windows Azure
MS Days 2011 - Windows AzureMS Days 2011 - Windows Azure
MS Days 2011 - Windows Azure
 
L'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOpsL'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOps
 
L’intégration, facteur clef de succès d’une transformation digitale
L’intégration, facteur clef de succès d’une transformation digitaleL’intégration, facteur clef de succès d’une transformation digitale
L’intégration, facteur clef de succès d’une transformation digitale
 
Architecture microservices avec docker
Architecture microservices avec dockerArchitecture microservices avec docker
Architecture microservices avec docker
 
Eucalyptus
EucalyptusEucalyptus
Eucalyptus
 
Azure et e commerce
Azure et e commerceAzure et e commerce
Azure et e commerce
 
eServices-Chp4: ESB
eServices-Chp4: ESBeServices-Chp4: ESB
eServices-Chp4: ESB
 
Integration Summit 16 - Keynote Integration Trends
Integration Summit 16 - Keynote Integration TrendsIntegration Summit 16 - Keynote Integration Trends
Integration Summit 16 - Keynote Integration Trends
 
Présentation evénement AWS - 13 oct 2015
Présentation evénement AWS  - 13 oct 2015 Présentation evénement AWS  - 13 oct 2015
Présentation evénement AWS - 13 oct 2015
 
Chp3 - ESB
Chp3 - ESBChp3 - ESB
Chp3 - ESB
 
Le design d'API avec Mulesoft
Le design d'API avec MulesoftLe design d'API avec Mulesoft
Le design d'API avec Mulesoft
 
Base donnes my_sql
Base donnes my_sqlBase donnes my_sql
Base donnes my_sql
 
PARTAGE par RENATER avec Cloudwatt & Netixia
PARTAGE par RENATER avec Cloudwatt & NetixiaPARTAGE par RENATER avec Cloudwatt & Netixia
PARTAGE par RENATER avec Cloudwatt & Netixia
 
Transformer votre Cloud : est-ce si simple ? La réponse avec les solutions EM...
Transformer votre Cloud : est-ce si simple ? La réponse avec les solutions EM...Transformer votre Cloud : est-ce si simple ? La réponse avec les solutions EM...
Transformer votre Cloud : est-ce si simple ? La réponse avec les solutions EM...
 
Azure Service Fabric pour les développeurs
Azure Service Fabric pour les développeursAzure Service Fabric pour les développeurs
Azure Service Fabric pour les développeurs
 

Mais de Gregory Boissinot (20)

Practical Software Architecture DDD
Practical Software Architecture DDDPractical Software Architecture DDD
Practical Software Architecture DDD
 
SOAT Agile Day 2017 DDD
SOAT Agile Day 2017 DDDSOAT Agile Day 2017 DDD
SOAT Agile Day 2017 DDD
 
DevDay2017 ESGI Essential DDD
DevDay2017 ESGI Essential DDDDevDay2017 ESGI Essential DDD
DevDay2017 ESGI Essential DDD
 
Beyond Relational Databases
Beyond Relational DatabasesBeyond Relational Databases
Beyond Relational Databases
 
Paris Redis Meetup Starting
Paris Redis Meetup StartingParis Redis Meetup Starting
Paris Redis Meetup Starting
 
Spring Integration JUG SummerCamp 2013
Spring Integration JUG SummerCamp 2013Spring Integration JUG SummerCamp 2013
Spring Integration JUG SummerCamp 2013
 
gradle_nantesjug
gradle_nantesjuggradle_nantesjug
gradle_nantesjug
 
gradle_lavajug
gradle_lavajuggradle_lavajug
gradle_lavajug
 
Jenkins-meetup
Jenkins-meetupJenkins-meetup
Jenkins-meetup
 
JENKINS_BreizhJUG_20111003
JENKINS_BreizhJUG_20111003JENKINS_BreizhJUG_20111003
JENKINS_BreizhJUG_20111003
 
JENKINS_OWF11_OSDC_PARIS20110924
JENKINS_OWF11_OSDC_PARIS20110924JENKINS_OWF11_OSDC_PARIS20110924
JENKINS_OWF11_OSDC_PARIS20110924
 
Gradle_Paris2010
Gradle_Paris2010Gradle_Paris2010
Gradle_Paris2010
 
Gradle_LyonJUG
Gradle_LyonJUGGradle_LyonJUG
Gradle_LyonJUG
 
Gradle_NormandyJUG
Gradle_NormandyJUGGradle_NormandyJUG
Gradle_NormandyJUG
 
Gradle_BreizJUG
Gradle_BreizJUGGradle_BreizJUG
Gradle_BreizJUG
 
Gradle_BordeauxJUG
Gradle_BordeauxJUGGradle_BordeauxJUG
Gradle_BordeauxJUG
 
Gradle_ToulouseJUG
Gradle_ToulouseJUGGradle_ToulouseJUG
Gradle_ToulouseJUG
 
Jenkins_UserMeetup_Paris_201105
Jenkins_UserMeetup_Paris_201105Jenkins_UserMeetup_Paris_201105
Jenkins_UserMeetup_Paris_201105
 
Gradle_ToursJUG
Gradle_ToursJUGGradle_ToursJUG
Gradle_ToursJUG
 
Gradle_YaJUG
Gradle_YaJUGGradle_YaJUG
Gradle_YaJUG
 

PZ_Microservices101_20150210

  • 1. @gboissinot   101   10  Février  2015  
  • 3. EMERGENCE DES MICROSERVICES Automa'sa'on   (build,  test,  deploy)   Consolidation d’expériences
  • 4. MICROSERVICES Les Microservices favorisent le découpage de son système d’information en de petites unités métiers indépendantes et autonomes Technique de décomposition «  Fine-­‐grained  architecture  »  
  • 5. APPROCHE MONOLITHIQUE UI  1   Code   Export   Code   PromoCon   Code   ApplicaCon  1   UI  2   Code   ReporCng   Code   Search  Engine   Code   ApplicaCon  2   BD   Store   Remote   Services   BD  Search  &   ReporCng   Import   Code  
  • 6. ON APPLIQUE LE CUBE DE SCALABILITÉ
  • 7. ARCHITECTURE MICROSERVICES UI  1   Code   Import  /   Export/   PromoCon   Service   UI  2   Code   ReporCng   Service   Search  Engine   Service   BD   Store   Remote   Services   Data   for  ReporCng   Data   For  Search   Première approche
  • 8. LES MICROSERVICES Pas de définition formelle mais un ensemble de caractéristiques 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ée Utilise un système d’inscription et de désinscription du réseau de Microservices
  • 9. ORIENTÉ « CAPACITÉ MÉTIER » «  Gather  together  those  things  that   change  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 Responsability Pattern (SPR) au système d’information
  • 10. La liberté des Microservices permet de réagir et de prendre des décisions plus rapidement à des changements inévitables (fonctionnels, techniques, organisationnels, etc) AU SERVICE D’UNE ARCHITECTURE AGILE Réduit le coût du changement Responsive   Elas'c   Resilient   Message   -­‐driven   Reac've  Manifesto  Pa?ern  
  • 11. FLEXIBILITÉ TECHNOLOGIQUE Service  1   «  Python  »     Document   Database     Service  2   Clojure     Graph   Database     Service  3   Java     SQL   Database     Attention: Trouver le bon compromis entre l’autonomie des équipes (avec la flexibilité du choix) et le besoin de standardisation Absorption des nouveaux besoins
  • 12. FAVORISE LA MIGRATION VERS DES ORGANISATIONS AGILES Service  1   C++   Service  2   Python   Service  3   Java   On crée des équipes pluridisciplinaires co- localisées orientées « Feature Métier » Build  &  Run   Build  &  Run   Build  &  Run   Autonomie et performance des équipes
  • 15. FLEXIBILITÉ DE REMPLACEMENT New     Service   Les architectures Microservices accélèrent l’innovation On diminue la résistance au « refactoring »
  • 16. Implication des Ops dans le métier Adapté aux nouvelles organisations Client / Fournisseur (Cloud, Infrastructure 2.0) DES BÉNÉFICES OPÉRATIONNELS Au service d’une infrastructure agile
  • 18. Application de la loi de Conway DES BÉNÉFICES ORGANISATIONNELS
  • 20. UNE INTERFACE DE COMMUNICATION SOUS FORME DE CONTRAT D’API IMPL   PUBLIC   API   Service   Une  bonne  API   •  AgnosCque  à  un   langage   •  Porte  la  logique   d’intégraCon   Votre API est votre contrat en regroupant l’ensemble des opérations exportables pour vos consommateurs. Elle doit évoluer indépendamment de votre code Un contrat dirigé par les attentes des consommateurs
  • 21. « ZONING DU SI» ?   De  nombreux   protocoles  et  API   d’intégraCon:   RMI   JAX-­‐RPC   JAX-­‐WS   JMS   SOAP/HTTP   REST/HTTP   AMQ   etc   Trouver  la  communicaCon  la   plus  simple  possible!  
  • 22. ON ÉVITE DE COLLABORER PAR LA DONNÉE 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. Shared     Database  
  • 23. MAIS POUR LE PARTAGE DE DONNÉES STATIQUES?     T_CODE_PAYS  
  • 24. DES SOLUTIONS À LA GESTION DES DONNÉES STATIQUES 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é
  • 25. ON ÉVITE DE COLLABORER À TRAVERS UN BUS D’INTÉGRATION Complex  IntegraCon  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
  • 26. ANALOGIE « TINKER TOY » Des « endpoints » intelligents et des communications simples
  • 27. COLLABORATION DES SERVICES ENTRE EUX Trouver un modèle de collaboration standard et efficace API  A   API  B   Protocole  A   Technologie  A   Format  de  données  A   Protocole  B   Technologie  B   Format  de  données  B   L’intégration doit être simple et favoriser le faible couplage des services Synchrone     ou     Asynchrone   Pas   d’intelligence  
  • 28. STYLES DE COLLABORATION 1) Request / Response (synchrone ou asynchrone) 2) Event Based (asynchrone) Service     1   Service     1   Service     2   Service     2   Event   subscribes  publishes  
  • 29. LE REMOTING, STYLE INTRUSIF 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 marshalling sont à prendre en compte Une promesse de transparence difficile à tenir
  • 30. LE MESSAGING A LA RESCOUSSE 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
  • 31. L’EXISTENCE DE REST « Identifiable Resources » « Uniform interface » « Stateless conversation » « Resource representations » « Hypermedia (HATEOS) » Un style d’architecture respectant un ensemble de contraintes
  • 32. « REST OVER HTTP » 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 Une forme de Messaging
  • 33. « UNIFORM INTERFACE » REST OVER HTTP Simplification d’accès HTTP   METHOD   Resource   names   +   Uniform   interfaces  
  • 34. HATEOAS – HYPERMEDIA AS THE ENGINE OF APPLICATION STATE 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 Découple le client et le serveur
  • 35. MODÈLE DE MATURITÉ DE RICHARDSON La maturité de la mise en œuvre de REST
  • 36. « EVENT-BASED COMMUNICATION » On publie des événements On souscrit à la réception d’événements A chaque changement, un événement est envoyé Utilisation d’un bus de messages
  • 37. « EVENT-BASED ARCHITECTURE » 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 La meilleure solution
  • 38. MicroServices « Chez les géants du Web »
  • 39. DES CARACTÉRISTIQUES COMMUNES 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
  • 40. NETFLIX HYSTRIX 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 failure cascade » en offrant des solutions de repli (fallback) Au service de la résilience globale
  • 43. LES AUTRES TECHNIQUES DE DÉCOMPOSITION 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  
  • 44. SHARED LIBRARY 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 techniques Le principe « DRY » ne doit être respecté qu’au sein d’un service Technique ou fonctionnel, favorise la réutilisabilité
  • 45. MODULES 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 On favorise le partage de code
  • 46. S’APPUYER SUR LES BOUNDED CONTEXT « A Bounded Context is a specific responsability enforced 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
  • 47. PENSER « COARSER-GRAINED » Toujours penser au service de plus haut niveau, puis affiner uniquement si nécessaire ensuite
  • 48. « COARSER-GRAINED » Packaging   Service   Metadata  Repo  Service   Import   Service   Export   Service   Promo'on   Service   Compa'bilityChecker   Service   Repor'ng   Service   Exemple Aucune  interac'ons   entre  les  services  de   plus  niveau   BOM   Service  
  • 49. ON ÉCRIT D’ABORD DU CODE 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 Microservices une base de code existante que de partir de Zéro On « refactore » ensuite
  • 50. ON NE CÉDER PAS À LA TENTATION On écrit des API qui répondent à des besoins réels et pas à des besoins futurs non identifié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
  • 51. Microservices Si on part d’un existant?
  • 52. ON TROUVE LES SEAMS 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
  • 53. ON SE REND CONFORME AUX ARCHITECTURES MICROSERVICES New   Service   Glue   Code   Monolith  
  • 54. DÉCOUPER EN SERVICES DEPUIS UN SEUL SCHÉMA DE BASE On découpe toujours d’abord les données pour éviter de collaborer par le système de persistance Import   Code   Monolithic   Schema   Monolithic  Service   PromoCon   Code   Import   Code   Import   Schema   PromoCon   Code   Promo Con   Schema   Import   Service   Import   Schema   PromoCon   Service   Promo Con   Schema   Monolithic  Service   1   2   3  
  • 55. MicroServices « Les points d’attention »
  • 56. AJOUT DE COMPLEXITÉ POUR LES DÉVELOPPEURS 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
  • 57. L’ENJEU D’UNE COMMUNICATION RÉSEAU 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é
  • 58. CAS D’UNE COMMUNICATION EXTERNE <person>    <firstname>Gregory<firstname>    <lastname>Boissinot<lastname>   </person>   <person>    <firstname>Gregory<firstname>    <lastname>Boissinot<lastname>    <twi?erid>gboissinot</twi?erid>   </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   « Tolerent Consumer & Conservative producer »
  • 59. ON MIGRE RAPIDEMENT service   v1   Client  1   Client  2   service   v1   Client  1   Client  2   service   Client  1   Client  2   v2   v2   temps   On conserve pas longtemps les anciennes versions Release  1   Release  2   Release  3  
  • 61. « SELF CONTAINED DEPLOYED MICROSERVICES » 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
  • 62. 1 SERVICE PAR « HOST » L’isolation 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
  • 63. LA VIRTUALISATION Une solution pour éviter d’avoir plusieurs machines physiques L’approche de la virtualisation est intéressante mais elle a coût Utilisation ou création d’images On peut « provisionner » 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)
  • 64. LA VIRTUALISATION Les problèmes 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
  • 65. LES CONTAINERS 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 légère. A la rescousse
  • 66. Host   UN SERVICE PAR CONTAINER Solution idéale avec le bon degré d’isolation Container   Service   Container   Service   Container   Service   Container   Service   Les Containers sont rapides à provisionner
  • 68. PLATEFORME 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 registre d’images Docker   1 Micro Service : 1 système Unix
  • 69. UN VASTE ÉCOSYSTÈME 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 cluster, etc)
  • 71. UN ÉCOSYSTÈME D’OUTILS POUR FACILITER LA MISE EN ŒUVRE TECHNIQUE
  • 73. 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 De bonnes idées mais un manque de maturité
  • 75. MICROSERVICES Ne cédez pas à toutes les possibilités offertes Surveillez, surveillez, … votre production! Synthèse 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
  • 76. MICROSERVICES Une stratégie à long terme Temps   #  de  services