@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