eServices-Chp5: Microservices et API Management

Microservices & API Management Chapitre 5 - eServices

GL5 2015/2016

Dr. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i

S l ide 1

Microservices

API Management

API Gateway

2

PLAN

Microservices Définition des Microservices Approche Monolithique vs Microservices Caractéristiques de l’Architecture Microservices

API Management

API Gateway

3

PLAN

Définition des Microservices

Style d’architecture Approche pour développer une seule application comme suite de petits services: •  Déployables les uns indépendamment des autres •  Chacun s’exécute sur son propre processus •  Communiquent via des mécanismes légers, souvent une ressource HTTP •  Constuits autours des compétences métier •  Peuvent être rédigés dans des langages et technologies différentes •  Peuvent utiliser des technologies de stockage de données diverses

4

Microservices

Approche Monolithique vs Approche Microservices

Approche Monolithique •  Application construire comme une seule unité •  Usuellement, les applications sont divisées en trois parties:

•  L’interface utilisateur •  Une base de données •  Une couche métier

•  La couche métier se charge de: Gérer les requêtes HTTP, Exécuter la logique du domaine, Extraire et modifier les données de la base de données, Sélectionner et charger les vues HTML…

•  Cela représente une application Monolithe •  Toute modification du système implique la compilation et déploiement d’une

nouvelle version de la couche métier


S l ide 5

Microservices


Approche Monolithique: Caractéristiques et Avantages •  Approche naturelle pour la construction d’un système •  Toute la logique métier tourne sur un seul processus •  Utilisation des caractéristiques de base de votre langage pour diviser

l’application en classes, packages, namespaces… •  Il est possible de lancer et tester l’application Monolithe sur la machine

du développeur, puis la déployer en production •  Il est possible d’utiliser un Load Balancer pour gérer la répartition de

charge entre plusieurs instances de cette application •  Applications qui produisent de bons résultats, rapidement conçues et

déployées Mais…


S l ide 6

Microservices


Approche Monolithique: Inconvénients •  Avec l’utilisation massive du cloud, les utilisateurs deviennet frustrés •  Les cycles de changement sont très reliés:

•  Une modification dans une petite partie de l’application requiert un rebuild et redéploiement entier

•  Il est difficile de garder une structure modulaire et une séparation des préoccupations

•  La mise à l’échelle d’une partie qui a besoin de plus de ressources requiert celle de toute l’application

Besoin de construire des applications sous formes de services indépendants


S l ide 7

Microservices


Approche Microservices

•  S’inspire des principes de conception du système UNIX •  loin d’être récents, mais peu considérés dans le développement logiciel

•  Services sont déployables indépendamment les uns des autres •  Mise à l’échelle plus facile et ciblée à chaque service •  Chaque service définit des limites bien fermes •  Chaque service peut être écrit dans un langage différent •  Chaque service peut être géré par une équipe différente


S l ide 8

Microservices



S l ide 9

Microservices

Architecture Microservices : Caractéristiques

Division en Composants via les Services •  S’inspirer du monde réel, qui est une association de composants reliés •  Composant: Unité logicielle qui est indépendamment remplaçable et

modifiable •  Utilisation simultanée de librairies et de services:

•  Librairies : composants reliés dans un programme et invoqués via des appels de fonctions in-memory

•  Services: composants out-of-process, communiquant via des mécanismes distants tels que les web services ou les appels de procédures distantes

•  Avantage des services: •  Indépendamment déployables : un changement dans un service ne nécessite

que le déploiement du service concerné •  Interface de composant plus explicite

•  Inconvénients des services: •  Appels distants plus coûteux


S l ide 10

Microservices


Organisation autours des Capacités Métiers •  La décomposition classique d’une application est souvent orientée vers

les couches techniques (vue, contrôle et modèle) •  Cela entraîne souvent que chaque changement touchera plusieurs équipes,

ce qui est coûteux en temps et en budget

•  Solution: Division logique des équipes •  Chaque service concerne un domaine

métier différent •  Les équipes sont inter-fonctionnelles, avec

tous les niveaux de compétences (UI, stockage et gestion de projet)


S l ide 11

Microservices

UI Métier BD

Service1

Service2 Service3


Produits, pas Projets •  Traditionnellement, l’effort de développement utilise un modèle de

projet: l’objectif est de livrer un logiciel complet •  À la fin du projet, le logiciel est transmis à une équipe de maintenance, et

l’équipe de développement est dissoute

•  Dans la vision Microservices, une équipe doit posséder un produit, durant tout son cycle de vie •  L’équipe de développement est entièrement responsable du logiciel produit •  « You build it, you run it » •  L’équipe reste au courant du comportement de son produit en production

•  Cette approche peut être prise pour les applications monolithiques, mais la granularité plus fine des services peut rendre plus efficace la relation développeur-client.


S l ide 12

Microservices


Extrémités Intelligentes et Canaux Stupides •  Plusieurs approches mettent beaucoup d’intelligence dans les canaux

de communication entre les services •  Exemple: ESB, avec des opérations sophistiquées pour le routage, la

chorégraphie, la transformation…

•  Les applications utilisant les microservices favorisent l’utilisation de communications sans intelligence, qui ne font que transmettre les messages, alors que le service lui-même fait le reste

•  Protocoles utilisés: •  HTTP pour les requêtes/réponses, principes et protocoles du web •  Bus de messagerie asynchrone et léger, ne faisant qu’un simple routage (ex:

RabbitMQ ou ZeroMQ)


S l ide 13

Microservices


Une Gouvernance Décentralisée •  Gouvernance centralisée => tendance à s’orienter vers une technologie et

plateforme unifiée •  Difficile de trouver une seule technologie qui résout tous les problèmes

•  Dans les architectures Microservices, chaque service pourra utiliser la technologie/langage/plateforme le plus adéquat pour ses besoins

•  Chaque équipe est responsable du service qu’elle réalise •  Responsabiliser les équipes et les obliger à fournir un code de qualité depuis le

début

•  Favoriser l’idée du partage, de l’open source, aider les autres développeurs à résoudre les mêmes problèmes

•  Abandonner l’idée classique des contrats de services pour des concepts plus modernes, plus légers, par ex: •  Tolerant Reader: le consommateur d’un service utilise uniquement les données

dont il a besoin pour éviter le dilemme du YAGNI (You Aren’t Going to Need IT)


S l ide 14

Microservices


Gestion des Données Décentralisée •  Le modèle conceptuel diffère entre les différents systèmes, ou services

d’une même application •  Décentralisation des décisions sur le stockage des données

•  Utilisation de bases de données différentes ou de différentes instances d’une même base de données, pour chaque service

•  Approche Polyglot Persistence: une variété de technologies de stockage pour plusieurs types de données

•  Architecture souvent distribuée, donc il est difficile d’assurer une consistance continue via le principe de transactions, car cela induit un couplage temporel et un problème de disponibilité •  Les Microservices optent plutôt pour le principe de consistance éventuelle


S l ide 15

Microservices


Automatisation de l’Infrastructure •  Devenue très populaire avec l’évolution du cloud •  Principes de:

•  Livraison Continue: le logiciel est développé de manière à ce qu’il puisse être livré en production à tout moment

•  Intégration Continue: les membres de l’équipe intègrent leur travail fréquemment, à raison de plusieurs intégrations par jour, chaque intégration étant vérifiée par un build et des tests automatiques

•  Besoin donc d’outils d’automatisation de l’infrastructure


S l ide 16

Microservices


Design for Failure •  Les applications sont conçues pour être tolérantes aux fautes •  Si un service est inaccessible, le client doit y répondre le plus

gracieusement possible •  Rajoute de la complexité par rapport à une application monolithique

•  Les équipes réfléchissent à l’impact de l’échec de chaque service sur l’utilisateur

•  Il faut que: •  Les failles soit détectées très rapidement •  Restaurer le service automatiquement, si possible

•  Le monitoring en temps réel des applications Microservices est très important


S l ide 17

Microservices


Conception évolutive •  La décomposition de services permet de contrôler les changements de

l’application sans les ralentir •  L’évolution de l’application est donc plus fluide

•  Les composants sont définis de manière à être indépendamment remplaçables et mis à jour •  Donc, la modification d’un composant ne devrait pas affecter ses

collaborateurs de manière significative

•  Utilisation d’un principe de la conception modulaire : définir la modularité suivant le patron du changement •  Regrouper dans le même module les éléments qui changent en même temps,

ou dont le changement de l’un affecte l’autre


S l ide 18

Microservices

Microservices

API Management Définition et Utilité

Challenges du API Management

Fonctionnalités du API Management

Solutions du API Management

Recommandations pour la Conception des APIs

API Gateway

19

PLAN

Mouvement Open API

•  Appelé aussi Public API •  Tendance qui autorise un accès à un logiciel propriétaire via une API

publique •  Exposition de certaines fonctionnalités du logiciel en protégeant les

autres •  Souvent une implémentation de REST •  Les Open APIs sont publiés sur Internet et partagés librement •  Permet d’encourager les développeurs d’autres entreprises (parfois

concurrentes) d’utiliser leur logiciel, et de se montrer innovants •  Facilite la création de Mashups à partir de plusieurs applications

•  Problème: •  Les utilisateurs des APIs sont dépendants de l’entreprise qui publie l’API

(modification de l’API, ajout de frais…)


S l ide 20

API Management

Définition

•  Entre dans le mouvement Open API, promu par de grands noms du web comme Facebook, Twitter et Google

•  Processus de publier, promouvoir et surveiller les interfaces de programmation des applications (APIs) dans un environnement sécurisé et extensible

•  Inclut la création d’un support pour définir et documenter ces APIs •  Permet de :

•  Gérer le cycle de vie de l’interface •  S’assurer que les besoins des consommateurs (développeurs et

applications) sont satisfaits

•  Favoriser les services légers REST et le format JSON aux services SOA classiques


S l ide 21

API Management

Challenges de l’API Management

•  Comment protéger les actifs de l’entreprise des éventuelles attaques ou abus?

•  Comment offrir votre API comme services fiables, sans temps d’arrêt qui peut nuire à des utilisateurs?

•  Comment gouverner l’accès et l’usage de l’API de manière consistante et de manière axée sur la politique (policy-driven)?

•  Comment gagner de l’argent grâce à vos APIs? •  Comment aider les utilisateurs à découvrir vos APIs et gérer leurs

accès eux-mêmes?


S l ide 22

API Management

Fonctionnalités des Outils de API Management

1.  Sécurité •  Protéger les données exposées •  Au moins, une gestion de l’ identité et un contrôle d’accès

2.  Gestion du cycle de vie de l’API •  S’assurer que les mises à jour ou versionning de l’API, ou tout mouvement

d’environnement, géographique des datacenters ou du cloud ne va pas impacter leur utilisation

•  Fournir des workflows pour: •  Promouvoir des APIs du développement à la production •  Gérer les métadonnées associées à la politique adoptée •  Restreindre les droits en modification en util isant un contrôle d’accès basé sur les

rôles (RBAC) •  Permettre les approbations et les rollbacks

3.  Gouvernance de l’API •  Définir les termes et conditions sous lesquelles une API est exposée à un ou

plusieurs consommateurs •  Contrôler et suivre la manière dont les APIs sont exposées aux différents

partenaires et développeurs, via des politiques , telles que les SLA, la disponibilité et la performance


S l ide 23

API Management


4.  Engagement du développeur et construction de la communauté •  Comment amener les développeurs à bord et les aider? •  Offrir un portail accessible pour les développeurs pour:

•  Supporter les différentes classes de développeurs (droits différents pour les partenaires et pour les développeurs publics, par exemple)

•  Fournir des capacités de self-service •  Donner aux développeurs la visibi l ité necessaire sur leur uti l isation de l ’API et les

métriques clefs de performance (temps de réponse par ex.) •  Permetre aux développeurs de partager les bonnes pratiques via un portai l communautaire

(ex. forum)

5.  Monétisation •  Permettre de monétiser l ’API si le besoin se présente •  Plusieurs modèles, par exemple:

•  Freemium: usage gratuit u dessus d’un certain seuil d’uti l isation •  Charger uniquement certaines fonctionnal ités •  Charger pour une certaine priorité d’usage ou pour une qual ité de service meil leure

6.  Disponibilité •  L’API doit être disponible, évolutive et redondante •  Le service doit pouvoir gérer tout type d’erreurs, problèmes ou congestion


S l ide 24

API Management


7.  Documentation •  Fournir un moyen facile de lire la documentation et la possibilité de

« essayer avant d’acheter » 8.  Analytics et Statistiques

•  Comprendre comment est-ce que les utilisateurs utilisent votre API

9.  Déploiement •  Doit être flexible, et doit supporter les clouds publics et privés

10.  Offrir un « Sendbox Environment » •  Environnement de test qui isole les changements et l’expérimentation de

l’environnement de production •  Permettre au consommateur de l’API de tester l’API avant de l’utiliser

11.  Gestion du traffic •  Contrôler le traffic et autoriser le caching pour un accès rapide aux pages

les plus visitées, gérer les quotas, détecter les congestions


S l ide 25

API Management

Types de Solutions de API Management

Proxies •  Solution entre l’utilisateur et l’application •  Fournissent des capacités de caching, et protection de l’infrastructure

des pics de traffic •  Problèmes : Augmentation des coûts et problèmes de latence Agents •  Utilisation du concept d’agents: plugins à intégrer dans votre serveur •  Pas de latence du réseau ni de dépendance •  Problème : difficulté d’implémenter la notion de caching Hybrides •  Possibilité d’utiliser un agent et un proxy •  Exemple: un agent pour le caching, et un proxy pour l’authentification


S l ide 26

API Management

Classement des Outils de API Management


S l ide 27

API Management

Gartner Magic Quadrant for Application Services Governance

Recommandations pour la Conception d’APIs

Voici quelques recommandations pour l’écriture d’une

« bonne » API, ce n’est pas la seule, peut-être pas la meilleure,

mais c’est celle définie par les développeurs d’apigee, l’un des

leaders en API Management, dans leur white paper:

Web API Design: Crafting Interfaces that Developers Love


S l ide 28

API Management

1. Accès aux ressources : Nouns are Good, Verbs are Bad

•  Garder votre URL de base simple et intuitive •  Utiliser seulement 2 URLs de base par ressource:

•  Une pour la collection : /dogs •  Une pour accéder à un élément spécifique de la collection (via son id) /dogs/1234

•  Éviter les verbes dans les URLs pour manipuler les ressources : les verbes HTTP, appliqués aux 2 URLs précédents, suffisent:


S l ide 29

Recommandations pour la Conception d'APIs

Ressource POST GET PUT DELETE

/dogs Créer un nouveau chien

Lister les chiens Modifier plusieurs chiens en masse

Supprimer tous les chiens

/dogs/1234 Erreur Afficher le chien 1234

Si le chien existe, l’afficher, sinon Erreur

Supprimer le chien 1234

2. Noms Explicites et au Pluriel

•  Il est plus lisible d’utiliser le pluriel pour représenter un type de ressources (/dogs)

•  Dans tous les cas, rester consistants: soit pluriel partout, soit singulier partout

•  Utiliser des noms explicites pour les ressources •  Éviter d’utiliser un type abstrait, pour que la ressource soit compréhensible

par le développeur •  Ex. utiliser /videos,/blogs,/articles au lieu de /items

pour représenter tous les types en un seul


S l ide 30


3. Simplifier les Associations

•  Une association entre deux ressources devrait être représentée de la manière suivante:

/ressource1/id1/ressource2 •  Par exemple, si on cherche les chiens du propriétaire 5678, on écrira:

/owners/5678/dogs


S l ide 31


4. Utiliser les Paramètres derrière le ‘?’

•  Éviter d’inclure des détails dans les URLs de base, utiliser les paramètres pour représenter les états optionnels:

•  Ex. Pour représenter tous les chiens rouges qui courent dans le parc:

GET /dogs?color=red&state=running&location=park


S l ide 32


5. Gestion des Erreurs

•  Les messages retournés par une API sont les seules indications sur le comportement de votre application, qui est une boîte noire pour le développeur

•  Utiliser les HTTP Status Codes •  Pas forcément les 70 codes,

mais les plus connus

•  Plus le message est verbeux, mieux c’est •  Inclure de préférence un lien

pour plus d’explications


S l ide 33


Code Description Signification

200 OK Ça marche!

201 Created La ressource a été créée

304 Not Modified Le client peut utiliser la version en cache de la ressource, car elle n’a pas été modifiée

400 Bad Request La requête du client est mal formulée

401 Not Authorized

Le client doit s’authentifier

403 Forbidden Le client n’a pas le droit d’utiliser la ressource

404 Not Found La ressource est inexistante

500 Internal Server Error

Il y’a un roblème au niveau de l’implémentation du service

6. Versionning

•  TOUJOURS inclure une version dans votre API •  La rendre obligatoire

•  Plusieurs manières de faire: •  Inclure un timestamp dans l’URL, qui va indiquer quand est-ce que la requête a

été créée, et choisir selon cela la version à utiliser •  Spécifier la version sous la forme Vxx dans l’URL •  Indiquer la version dans le header

•  Recommandation: •  Spécifier la version dans l’URL •  Utiliser le préfixe ‘v’ •  Le définir au début de l’URL, de manière à ce qu’il ait un haut niveau

hiérarchique •  Utiliser un nombre ordinal simple (v1, v2, …) plutôt que v1.2, v2.4, car la

granularité du versionning d’une API doit être assez gros (contrairement à une implémentation, qui peut évoluer à plusieurs reprises)


S l ide 34


7. Réponse Partielle

•  Une réponse partielle permet de donner aux développeurs l’information dont ils ont besoin uniquement, en sélectionnant les champs affichés dans la réponse

•  Utiliser une liste optionnelle séparée par des virgules pour indiquer les champs à afficher, ex. :

/dogs?fields=name,color,location


S l ide 35


8. Pagination

•  La pagination permet de limiter les enregistrements retournés d’une base de données.

•  Utiliser les mots clefs : •  Limit : pour indiquer le nombre d’éléments retournés •  Offset: pour indiquer le rang de départ Par exemple, la requête:

/dogs?limit=25&offset=50 Retourne les enregistrements de 50 à 75

•  Il serait judicieux d’insérer dans chaque réponse des métadonnées indiquant au développeur le nombre total d’enregistrements disponibles


S l ide 36


9. Accès aux URIs Fonctionnels

•  Il est possible de définir des APIs qui retournent autre chose qu’une ressource ou qui déclenchent un traitement distant particulier

•  Pour cela, utiliser des verbes, pas des noms •  Indiquer clairement dans l’API que ce sont des opérations

fonctionnelles, pas des ressources •  En ajoutant un préfixe à leur URI, comme func, par exemple •  En les définissant dans une section différente de la documentation

http://.../api/func/calculateTax?state=fl&amount=10


S l ide 37


10. Support de Plusieurs Formats

•  Il est recommandé de supporter plusieurs formats de réponse •  I l est possible d’automatiser le mapping d’un format à un autre

•  Il est recommandé d’indiquer dans l’URI le format désiré pour la réponse, en l’ajoutant comme extension •  C’est clair, intuitif, et demande peu de caractères supplémentaires

/dogs/1234.json

•  Le format par défaut recommandé est JSON •  La plupart des projets utilisent Javascript comme front-end •  I l est moins verbeux que XML


S l ide 38


11. Noms des Attributs

•  Il est recommandé d’utiliser les conventions Javascript pour le nommage des attributs dans la réponse JSON

•  Utilisation du CamelCase •  Majuscule ou minuscule selon le type de l’objet

"createdAt": 1320296464


S l ide 39


12. Recherche

•  Pour une recherche globale, utiliser le mot clef search, et ?q pour représenter la requête

/search?q=fluffy+fur

•  Pour faire une recherche plus précise, précéder la requête du domaine de recherche

/owners/5678/dogs?q=fluffy+fur


S l ide 40


13. Domaine de l’URI

•  Il est recommandé de consolider toutes les requêtes d’API sous un même sous-domaine •  C’est plus propre, et plus facile pour les développeurs

•  Définir un nom de domaine unique (votre API gateway) api.techdogrest.com

•  Définir un portail dédié pour les développeurs developers.techdogrest.com

•  Définir des redirections pour les requêtes venant du navigateur web: •  Un appel du domaine de l’API du navigateur devrait être redirigé vers le portail

des développeurs •  Utilisation de dev ou developer au lieu de developers devrait être redirigé vers

developers.techdogrest.com


S l ide 41


Microservices

API Management

API Gateway Pourquoi utiliser les APIs Gateways Avantages et Inconvénients des APIs Gateway Rôles du API Gateway

42

PLAN

Problèmes…

•  L’utilisation des microservices dans une application implique que les APIs fournies sont de grain fin •  Un client a donc besoin d’interagir avec plusieurs services pour réaliser une

opération

•  Des clients différents ont besoin de données différentes pour représenter la même chose •  Par exemple, la version web et la version mobile d’une page de détails d’un

produit ne représentent pas les mêmes éléments

•  La performance du réseau est différente pour chaque client •  Un réseau mobile est plus lent et avec une latence plus haute qu’un réseau fixe •  Une application web côté serveur peut faire beaucoup de requêtes aux services

back-end sans impacter l’UX, alors qu’une application mobile ne peut en faire que très peu

•  Les services et leurs emplacements (port et hôte) peuvent changer


S l ide 43

API Gateway

Solution

•  Utilisation d’un API Gateway, un point d’entrée unique pour tous les clients

•  Permet de gérer les requêtes: •  Soit par simple routage au service approprié •  Soit en les distribuant sur plusieurs services

•  Peut exposer une API différente pour chaque client •  Peut implémenter la sécurité

•  Contrôle d’accès aux APIs


S l ide 44

API Gateway

Avantages

•  Permet de rendre transparent le partitionnement de l’application en microservices

•  Évite au client la charge de connaître les emplacements de toutes les instances de services utilisées

•  Fournit l’API optimale pour chaque client •  Réduit le nombre de requêtes et d’aller-retours, en

permettant l’extraction de données à partir de plusieurs sources en une seule requête •  Idéal pour les applications mobiles

•  Simplifie le traitement côté client en déplaçant la logique d’orchestration du client vers le gateway


S l ide 45

API Gateway

Inconvénients

•  Augmentation de la complexité •  Un middleware supplémentaire qui doit être configuré, déployé

et géré

•  Augmentation du temps de réponse dû au saut supplémentaire pour appeler le gateway •  Peut être négligeable comparé au temps d’aller-retour pour la composition

de services


S l ide 46

API Gateway

Rôles du API Gateway

•  Auhentification •  Authentification pour chaque requête ou série de requêtes •  Définit des règles d’accès aux services •  La plupart des Gateways ajoutent les informations d’authentification aux

requêtes faites aux services en arrière plan •  Permet de développer une logique spécifique à l ’utilisateur au niveau des

microservices

•  Sécurité du Transport •  Étant le point d’entrée unique aux APIs publiques, il doit sécuriser les accès

aux microservices •  Utilisation d’un protocole sécurisé pour l’accès au Gateway (par exemple

SSL) puis suppression ou changement des contraintes de sécurité entre le gateway et les services


S l ide 47

API Gateway


•  Répartition de Charge •  Distribution des requêtes parmi les instances de microservices •  Répartir la charge entre les différents services selon leurs contraintes

respectives •  Le gateway peut demander la création dynamique de nouvelles instances de

service si les instances existantes ne sont pas suffisantes

•  Dispatching des Requêtes •  Le gateway peut travailler en tandem avec les Service Registries pour router

les requêtes vers le bon service •  Gestion du routage des services inexistants ou obsolètes


S l ide 48

API Gateway


•  Résolution de Dépendances •  Fournir des façades (point d’entrée virtuels) qui routent les requêtes

systématiquement à plusieurs micorservices différents •  Éviter ainsi les appels répétés vers un ensemble de microservices pour

réaliser une seule fonctionnalité •  Phénomène des architectures bavardes (chatty)

•  Transformation •  Adapter les requêtes des clients aux formats utilisés par les services, sans

déranger les deux parties •  Conserver l’indépendance du développeur de l’API ainsi que du client


S l ide 49

API Gateway

Articles •  Martin Fowler, Microservices , http://martinfowler.com/articles/microservices.html rédigé le

25/03/14, consulté le 13/11/15

•  Margaret Rouse, API Management , http://searchcloudapplications.techtarget.com/definition/API-management rédigé en septembre 2014, consulté le 29/11/15

•  George Psistakis, API Management tools: How to find the one for you http://www.developereconomics.com/api-management-tools-how-to-find-the-one-for-you/, rédigé le 23/03/15, consulté le 29/11/15

•  Chris Richardson, MicroServices Patterns and Best Practices , http://microservices.io/ rédigé en 2014, consulté le 6/12/15

•  Sebastiàn Peyrott, An Introduction to Microservices part 2: The API Gateway , https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/ rédigé le 13/09/2015, consulté le 6/12/15

White Papers •  Choosing the Right API Management Solution for the Enterprise User , CA Technologies White

paper, september 2014

50

Sources

eServices-Chp5: Microservices et API Management

Technology

Transcript of eServices-Chp5: Microservices et API Management