Comment construire (et faire évoluer)

les systèmes avec les microservices

 Comment construire (et faire évoluer) les systèmes avec les microservices

Table des matières

Chapitre 1 : Présentation des microservices.............................................................................................. 3
Chapitre 2 : Les microservices en tant que projet d'entreprise.................................................................. 7
Chapitre 3 : La migration vers les microservices...................................................................................... 10
Chapitre 4 : Les défis liés à la visibilité et au monitoring.......................................................................... 14

2
Chapitre 1 : Présentation des microservices
 Chapitre 1 : Présentation des microservices

Les microservices correspondent à un type d'architecture logicielle dans laquelle les grosses applications
sont conçues à partir de petites unités autonomes qui interagissent via des API indépendantes du
langage logiciel utilisé. Chaque service a une portée limitée, se concentre sur une seule tâche et est
totalement indépendant. Cette configuration permet aux directeurs IT et aux développeurs de construire
des systèmes modulaires. Dans son livre intitulé « Building Microservices » (Construire les microservices),
Sam Newman définit les microservices comme des petits composants spécialisés dans l'exécution
parfaite d'une seule tâche.
L'un des textes fondateurs des microservices est l'article de Martin Fowler, intitulé « Microservices
- a Definition of This New Architectural Term » (Microservices : une définition de ce nouveau terme
d'architecture). L'auteur distingue cinq caractéristiques principales des microservices :
– Subdivision en composants : Les microservices sont des unités indépendantes, facilement
remplaçables et actualisées. Ces unités recourent à des services, tels que des appels de procédure
à distance ou des demandes de service Web, pour communiquer.
– Fonctionnalités d'entreprise : Le développement d'applications traditionnelles amène souvent le
personnel à être réparti par exemple en « équipe côté serveur » et « équipe base de données ».
Le développement des microservices est axé sur la fonctionnalité d'entreprise, avec une
responsabilité pour toute une série de fonctions couvrant l'expérience utilisateur et la gestion
de projet.
– Des produits plutôt que des projets : Au lieu de se concentrer sur un projet logiciel qui est livré
une fois terminé, les microservices traitent les applications comme des produits dont ils ont la
responsabilité. Ils établissent un dialogue continu visant à faire correspondre en permanence
l'application à la fonction commerciale.
– Connexions simples et points d'accès intelligents : Les applications microservices ont leur propre
logique. Les ressources souvent utilisées sont facilement mises en cache.
– Gouvernance décentralisée : Des outils sont développés et partagés pour traiter les problèmes
Composants logiciels individuels Fonctionnalités commerciales
similaires à ceux rencontrés dans d'autres équipes.
REST
Versions séparées
Application Web Application catalogue
Gouvernance décentralisée
Histoire des microservices
L'expression « Micro-Web-Services » a été utilisée pour la toute première fois lors d'une conférence sur
le cloud computing par le Dr. Peter Rodgers, en 2005, et le terme « microservices » a fait son apparition
lors d'une conférence d'architectes de logiciels au printemps 2011. Ils sont de plus en plus connus car ils
permettent de gérer les nombreux changements du monde de l'informatique actuel, tels que :
– Appareils mobiles
– Applications Web
– Conteneurisation des systèmes d'exploitation
– RAM bon marché
– Utilisation des serveurs
– Serveurs multicœurs
– 10 Gigabit Ethernet
Le concept de microservices n'est pas nouveau. Google, Facebook et Amazon utilisent cette approche
à différents degrés depuis plus de dix ans. Une simple recherche avec Google, par exemple, fait appel à
plus de 70 microservices avant d'afficher la page de résultats.
De plus, d'autres architectures capables de résoudre certains des problèmes que les microservices
permettent de traiter ont été conçues. Parmi celles-ci, l'architecture orientée services (SOA) fournit des
services aux composants via un réseau. Dans cette architecture, tous les services peuvent échanger
des données entre eux. Elle a par contre l'inconvénient de ne pas pouvoir traiter les communications
asynchrones.
La différence entre les microservices et l'architecture orientée services
L'architecture orientée services (SOA) est une structure logicielle dans laquelle les composants assurent
des services suivant un protocole réseau. Cette approche a connu beaucoup de succès de 2005 à 2007
mais suscite moins d'enthousiasme depuis l'arrivée des microservices. Quand les microservices ont pris
l'avantage il y a quelques années, certains ingénieurs les appelaient « SOA à fine granularité ». D'autres
ont dit qu’ils effectuaient ce que la SOA aurait dû faire dès le départ.
Une SOA est une approche différente des microservices. Alors qu’une SOA supporte le Web Services
Definition Language (WSDL), qui fixe les points d'accès du service de manière très typée, les
microservices disposent de connexions toutes simples et de points d'accès intelligents. Une SOA n'a

pas d'état alors que les microservices en ont de nombreux et utilisent des structures de programmation
ST
RE Équipe de développement Équipe de développement orientée objet (POO) qui rassemblent les données et la logique.

Parmi les difficultés posées par une SOA :

RE
ST

– Une SOA est lourde, complexe et implique plusieurs processus qui peuvent affecter la vitesse de
Application client RE
ST traitement.
– Même si la SOA permettait au départ d'éviter le verrou imposé par les équipementiers, elle n'a
Équipe de développement
REST finalement pas réussi à évoluer au rythme de la démocratisation des IT.
– De la même manière que CORBA a été délaissé quand les premières innovations Internet ont
API de service Web Application d'analyse
facilité la mise en œuvre des applications pour le Web, la SOA est devenue moins prisée quand les
microservices ont permis de mieux intégrer les services Web.
Équipe de développement Équipe de développement

Équipes de développement individuelles

4
 Chapitre 1 : Présentation des microservices

Les problèmes résolus grâce aux microservices Allan Naim, responsable produits chez Google, également présent au panel, partageait ce point de vue.
Il a expliqué que la SOA était destinée aux systèmes d'entreprise en raison de son besoin de registre
Les grandes entreprises rencontrent des problèmes si leurs architectures en un seul bloc ne peuvent pas
de services, de référentiel de services et d'autres composants particulièrement coûteux à acheter
évoluer, être facilement mises à niveau ou entretenues à mesure qu'elles se développent. L'architecture
et entretenir. De plus, ces composants sont isolés les uns des autres. Les microservices résout des
des microservices résout ce problème. Il s'agit d'une architecture logicielle dans laquelle les tâches
problèmes que la SAO tentait de régler il y plus de dix ans, mais avec une plus grande ouverture.
complexes sont divisées en petits processus autonomes communiquant par API indépendantes du
langage.
Différence des microservices selon les plateformes
Les applications monoblocs sont constituées d'une interface utilisateur sur le client, d'une application
Les microservices sont une approche conceptuelle qui se traite différemment selon chaque langage.
sur le serveur et d'une base de données. L'application traite les requêtes HTTP, tire les informations de la
C'est l'un des avantages de cette architecture, car les développeurs peuvent utiliser le langage qu'ils
base de données et les envoie au navigateur. Les microservices traitent la requête/réponse HTTP par API
maîtrisent le mieux. Les langages les plus anciens peuvent utiliser les microservices en se basant sur une
et messages. Ils répondent par langage JSON/XML ou HTML envoyé aux composants de présentation.
structure spécifique à leur plateforme. Voici certaines caractéristiques des microservices sur différentes
Les adeptes des microservices s'opposent farouchement aux normes imposées aux architectures dans
plateformes :
les grandes entreprises mais adoptent avec enthousiasme des formats ouverts comme HTTP, ATOM, etc.

À mesure que les applications se développent, les connexions et les dépendances deviennent plus Java
complexes. Qu'il soit question d'une architecture en un seul bloc ou d'unités plus petites, on peut répartir
– Évite d'utiliser les fichiers Web Archive ou Enterprise Archive.
l'ensemble en composants avec les microservices. Cela permet une évolution d'échelle au même niveau
et facilite la gestion et la maintenance des différents composants. – Les composants ne sont pas auto-déployés. Des conteneurs Docker ou des Amazon Machine Images
le sont à la place.
Lien entre les microservices et DevOps – Utilise des fat jars pouvant être exécutés en tant que processus.
L'intégration d'une nouvelle technologie n’est qu'une partie du problème. Un défi plus important
PHP
à relever est sans doute le développement d'une nouvelle culture encourageant la prise de risque
et de responsabilité sur le cycle de vie complet du projet. Les développeurs habitués aux systèmes Des microservices PHP de type REST sont déployés depuis déjà plusieurs années car ils sont :
traditionnels peuvent être désorientés par cette soudaine autonomie. Il est alors essentiel de définir
– Très flexibles au niveau de l'entreprise.
clairement les attentes en termes de responsabilité et de performances pour chaque membre
de l'équipe. – Facilement et rapidement testés.

Une approche DevOps est cruciale pour déterminer le cadre d'utilisation des microservices. Cette Python
décision est importante car associer des microservices à des systèmes monoblocs existants et saturés
Il est simple de créer un service Python servant de service Web front-end pour les microservices dans
peut parfois être une tentative vouée à l'échec. Les modifications ne peuvent pas intervenir assez
d'autres langages tels qu'ASP ou PHP.
rapidement. Avec les microservices, le développement des services est continu et leur ajustement
à la volée. Les équipes DevOps doivent assurer la mise en production des composants actualisés, Un grand choix de frameworks performants, comme Flask ou Django, est proposé.
en travaillant étroitement avec les intervenants internes et les fournisseurs sur les mises à jour.
Il est important de bien comprendre l'API pour accélérer le prototypage.
Vers des applications plus simples Possibilité d'utiliser Pypy, Cython, C++ ou Golang s'il faut plus de vitesse ou d'efficacité.
Lors d'un panel organisé à la conférence Appsphere 15, Doug Sherman du studio d'animation
DreamWork a indiqué que la tentative d'adoption d'une approche SAO il y a quelques années
s'était finalement avérée contre-productive. L'avis de Sherman est que l'univers IT se dirige vers des
applications plus simples. La SOA a pu paraître plus complexe qu'elle n'aurait dû l'être. Les microservices
sont alors apparus comme une solution plus simple que la SOA. De manière similaire, JSON avait été
considéré moins compliqué que XML et REST plus pratique que SOAP. Nous nous dirigeons vers des
systèmes plus faciles à établir, déployer et maîtriser. La SOA avait été conçue ainsi au départ, même si
elle s'est finalement avérée plus complexe que nécessaire.

5

Node.js
Node.js est un choix naturel pour les microservices, car c'est le langage des applications Web modernes.
Parmi ses avantages :
– S'appuie sur JavaScript et tire parti du puissant moteur open-source V8 de Google.
– Code machine optimisé de façon dynamique pendant l'exécution.
– Processus du serveur HTTP légers.
– E/S non bloquantes, pilotées par événements.
– Gestion des paquets de haute qualité.
– Création facile de paquets pour les développeurs.
– Haute évolutivité par E/S asynchrones de bout en bout
.NET
Au début des années 2000, .NET était l'une des premières plateformes à créer des applications en tant
que services à l'aide du protocole SOAP (Simple Object Access Protocol), dans un but comparable à celui
des microservices modernes. Aujourd'hui, l'un des avantages de .NET est sa forte présence en entreprise.
Voici deux exemples d'utilisation des microservices avec .NET :
– Développement de service Web auto-hébergé .NET avec Open Web Interface for .NET (OWIN).
Il est ensuite possible de l'utiliser pour intégrer des microservices.
– Création d'une entreprise spécialisée dans les ressources humaines dématérialisées.
Chapitre 1 : Présentation des microservices
Répondre à un marché en pleine évolution
Le passage aux microservices est flagrant. La convergence de l’informatique mobile, du cloud
computing, des équipements et du stockage bon marché suscite un grand enthousiasme pour cette
nouvelle approche. En fait, les entreprises n'ont pas vraiment le choix. Matt Miller a tiré la sonnette
d'alarme dans un article paru dans The Wall Street Journal, intitulé « Innovate or Die: The Rise of
Microservices » (Innover ou mourir : l'avènement des microservices). Il y explique que les logiciels sont
devenus le principal élément différenciateur des entreprises dans tous les secteurs. Les programmes
monoblocs répandus dans de nombreuses entreprises ne peuvent pas être modifiés assez rapidement
pour s'adapter aux nouvelles réalités et exigences en matière de concurrence.
L'architecture orientée services avait tenté de résoudre cela en partie. Elle n'a cependant pas réussi à
s'imposer durablement. Les microservices ont fait leur apparition au moment où ces problèmes ont
atteint leur paroxysme. Ils sont flexibles, résilients et efficaces, contrairement à de nombreux systèmes
classiques en place. Certaines grandes entreprises comme Netflix, Paypal, Airbnb et Goldman Sachs ont
été attentives à ce type d'alerte et se mettent rapidement aux microservices.
6
Chapitre 2 : L
 es microservices en tant que
projet d'entreprise

Pour que les microservices fonctionnent au sein d'une entreprise, ils doivent être associés à un projet
d'entreprise. Certains professionnels IT se demandent si les microservices conviennent uniquement
aux applications Web géantes comme Google et Facebook. Cependant, la flexibilité apportée par les
microservices à l'entreprise n'est que l'un de leurs avantages.
Dans l'environnement informatique actuel, innovation et vitesse sont capitales. L'enthousiasme envers les
microservices découle du besoin de créer de nouveaux logiciels capables d'améliorer et de perfectionner
un système monobloc, mais séparés de ce dernier. Ce découplage avec le système existant permet de
tester librement de nouvelles approches et d'itérer rapidement les changements et les modifications.
Les systèmes classiques ne peuvent pas être remaniés de cette façon et risquent de désavantager
les entreprises. Lors de la conférence Appsphere 15, Boris Scholl de Microsoft est revenu sur un cas
rencontré par son entreprise avec un système monobloc. Le système était si complexe que lorsqu'on
ajoutait de nouvelles lignes de code, le système s'arrêtait et il fallait alors deux jours aux ingénieurs pour
trouver la cause. C’est beaucoup trop lent.
Les entreprises essaient de déterminer la place que les microservices doivent occuper dans leurs
systèmes. Avant, les développeurs se préoccupaient uniquement du code, mais aujourd'hui, avec
l'approche technologique modulaire, ils doivent élargir leur vision à toutes les technologies mises en
œuvre et à leur interaction. Ils partagent désormais la responsabilité du projet dans son ensemble -- une
vue au niveau « micro » sur l'élément dont ils sont directement responsables, comme la programmation
de l'expérience utilisateur, par exemple, et une vue au niveau « macro » sur le produit fini, comme une
application de home banking, par exemple.
Dès le déploiement, le code doit faire l’objet de monitoring. La boucle de rétroaction est instantanée.
Une approche DevOps peut suivre une cinquantaine de microservices différents. Les données sont
disponibles immédiatement. Cela signifie que les services IT doivent effectuer monitoring, ajustement et
modification à la volée. C'est un véritable défi.
Analyse commerciale des microservices
Lors du panel de l'Appsphere 15, Allan Naim, responsable produits des divisions Container Engine et
Kubernetes chez Google, a précisé que l'intégration des microservices au sein des organisations IT
n'était pas simple et qu'elle nécessitait la mise en place d'un projet d'entreprise. En général, les objectifs
commerciaux sont présentés par le PDG et le conseil d'administration. Ensuite, le directeur marketing
ou le responsable de sécurité informatique commence à les mettre en œuvre et le personnel IT doit
alors travailler avec les microservices. Naim a ajouté que, selon lui, à court terme, toutes les entreprises,
indépendamment de leur secteur ou de leur marché, dépendront des logiciels. Ceci s'explique par la
valeur attribuée aux données client, devenue équivalente à celle des produits ou services.
Pour en profiter, les entreprises doivent agir rapidement et modifier leurs offres en fonction de
l'environnement, en constante évolution. Les applications classiques s'adaptent difficilement
aux nouvelles exigences du marché comme la mobilité et l'Internet des objets. La concurrence,
particulièrement celle des start-ups agressives qui cherchent à bouleverser tout un secteur, force les
entreprises à intégrer l'architecture microservices dans leurs systèmes, que les données soient dans une
base de données relationnelle ou non.
Chapitre 2 : Les microservices en tant que projet d'entreprise
Moins de spécialisation, plus de flexibilité
L'important, en fin de compte, est de fournir des logiciels de haute qualité à un grand nombre de clients
aussi vite que possible. Les microservices ne changent pas seulement la manière de programmer,
ils transforment aussi les entreprises. Par exemple, dans un système monobloc, le rôle de chaque
membre de l'équipe était généralement hautement spécialisé.
Dans le monde des microservices, cette approche est à éviter. Il vaut mieux donner plus de liberté
à chaque membre d'équipe pour qu'il puisse travailler sur différentes parties de l'application sans
discontinuité. Au lieu de développer l'application par segments, celle-ci est constamment surveillée
et modifiée lors de sa conception.
Outils internes d'analyse et de monitoring
Ces pressions du marché ont engendré une autre innovation : les services IT ont commencé à concevoir
leurs propres outils. Netflix a créé son propre système de monitoring. L'entreprise a personnalisé des
outils disparates, une approche bien différente de celle adoptée par des entreprises comme Facebook
et Google.
Par exemple, le service IT de Netflix a mis au point son propre logiciel d'analyse afin de traiter d'énormes
volumes de données. De quelle quantité est-il question au juste ? Le chiffre suivant est assez éloquent :
le prestataire de solutions réseau Sandvine a indiqué que les clients Netflix regardant des films en
streaming représentaient un peu plus de 30 % du trafic sur le Web en première partie de soirée.
Le développement des microservices modifie bien plus que le code des logiciels. Cela a un impact
considérable sur la façon dont les entreprises conçoivent leurs processus commerciaux, sur le choix
de produits commercialisés et sur leur soutien auprès de clients sur le marché.
Étant donné l'essor fulgurant des appareils mobiles et l'évolution continue des besoins et souhaits des
consommateurs, les professionnels IT doivent s'adapter aussi vite. L'architecture microservices est
pour eux le moyen de réagir rapidement. Cela ne change pas seulement la technologie, mais aussi la
façon dont les entreprises évaluent les opportunités commerciales. À un autre niveau, cela impacte
l'organisation des compétences, encourage une culture de l'innovation, élargit le périmètre des
responsabilités individuelles et permet aux plus avisés de saisir des opportunités.
Flexibilité et vitesse sont capitales
Les grandes entreprises comme Condé Nast et Gilt ont toujours été capables de gérer de gros volumes
de données client. Elles sont toutefois tournées vers l'avenir et adaptent leurs systèmes existants pour
utiliser une architecture microservices. Elles veulent se débarrasser des dépendances et être en mesure
de tester et de déployer rapidement des changements de code. Les entreprises mettent en œuvre des
changements similaires qui leur permettent de s'adapter plus facilement aux besoins des clients. Cela les
encourage également à exploiter davantage le cloud pour gagner en flexibilité et en vitesse.
L'approche de l'architecture microservices est comparable à celle rencontrée dans d'autres méthodes de
développement rapide comme la méthode agile. Les entreprises avec une plateforme Web à évolution
rapide comme Netflix recherchent constamment la simplicité et la possibilité d'apporter des modifications
rapides sans passer par plusieurs comités. Il y a peu de code et tous les ingénieurs informatiques
apportent des modifications de façon continue.
8
 Chapitre 2 : Les microservices en tant que projet d'entreprise

Un changement radical dans le développement des logiciels
Voilà pourquoi l'architecture microservices convient aux langages Web particulièrement adaptés aux
petits composants, comme Node.js. Les entreprises souhaitent agir vite et apporter rapidement des
modifications à leurs applications. Étant donnée l'autonomie des microservices, les modifications du
codebase, tout comme le remplacement ou la suppression de services, peuvent se faire facilement.
Au lieu de réécrire un module entier et d'essayer de propager les modifications dans un codebase massif,
il suffit simplement d'ajouter un microservice. De plus, tous les autres services peuvent ensuite se servir
de la fonctionnalité du service ajouté de façon instantanée.
Faire tomber les barrières
En fait, les microservices font tomber les barrières entre le développement des logiciels et leur opération.
Cela signifie qu'une entreprise envisageant d'utiliser les microservices à grande échelle doit d'abord
s'assurer qu'elle est prête à fonctionner avec cette nouvelle approche.
Cela ne signifie pas que les systèmes présents doivent être délaissés pour le nouveau venu.
Dans de nombreux cas, le système classique fonctionne très bien pour l'entreprise. C'est pourquoi
il serait absurde de le changer sans procéder à une analyse de rentabilité.

Cela change radicalement le développement logiciel. Le rythme des modifications du code dans les Toutefois, les grandes tendances de ces dernières années, comme le cloud computing, l'adoption des
applications mobiles et sur les sites Web est bien trop rapide pour les systèmes de développement appareils mobiles et le haut débit à bas prix modifient de façon irréversible la façon dont les clients
classique de logiciels. Il faut une nouvelle façon de concevoir ces applications en constante évolution. achètent et consomment les applications. Le rythme du changement est vertigineux. C'est pourquoi
il est primordial de développer des applications rapidement.
Évolution de la structure des entreprises
Dans les années 1980, le rôle des services IT a commencé à changer avec l'arrivée du PC.
Chaque année, les PC devenaient plus puissants, et le personnel technique devait non seulement
soutenir chaque fonction métier, mais également maintenir des processus complets. Le rôle des
technologies et des données se rapprochait du cœur des compétences de l'entreprise.

Dans les années 1990, le service IT était devenu un élément essentiel de toutes les grandes entreprises.
Dès que le système informatique était en panne, même pour un court instant, cela provoquait des
problèmes dans tous les services de l'entreprise.

Conception orientée données

Avec les microservices, on peut exploiter les données de chaque microservice uniquement via son API
associée. Les données au sein du microservice sont confidentielles. C'est pour cette raison que leur
association peut être souple, ce qui leur permet de fonctionner et d'évoluer de façon indépendante.
Cela pose deux difficultés : le maintien de la cohérence à travers différents services et la mise en œuvre
de requêtes pour obtenir des informations de plusieurs services. Avec une conception orientée données,
on peut tester et créer des transactions auprès de plusieurs services de façon cohérente.

Malheureusement, de nombreuses entreprises conservent leur ancien modèle de conception logicielle.

Elles sont toutefois contraintes aujourd'hui d'accélérer la délivrance de nouvelles applications Web et
mobiles à leurs clients. La vitesse est devenue la nouvelle monnaie.

Changement de culture dans les services IT

L'essor des microservices change une culture profondément ancrée dans les services IT. Il y a toujours
eu une séparation entre les équipes de développement et d'opération. Mais aujourd'hui, avec l'approche
DevOps, le développement des logiciels implique une collaboration plus étroite que jamais. Pendant de
nombreuses années, les services IT se sont basés sur des normes établies pour choisir la technologie
à utiliser. Ces technologies représentant de lourds investissements en termes de temps et d'argent,
ils calculaient soigneusement le budget de capacité, des mises à niveau et de la sécurité.

Dans le nouveau monde des microservices, les responsables IT doivent revoir totalement leur
organisation, en donnant un plus grand rôle aux développeurs dans le monitoring des applications,
tout au long de leur cycle de vie, du développement à la production. Curieusement, une situation
similaire s'est présentée il y a plusieurs décennies : les centres de données étaient si complexes que seuls
quelques ingénieurs IT savaient utiliser toutes les différentes fonctions. Souvent, le personnel en charge
de l'entretien des applications était le même que celui qui les avait conçues.

9
Chapitre 3 : La migration vers les microservices

Nous nous dirigeons à toute vitesse vers un monde mobile basé sur les technologies digitales et
« always-on » (toujours connecté). Les entreprises qui ne parviennent pas à changer leur approche
technologique se retrouveront à la traîne, derrière celles qui ont réussi à intégrer une architecture
flexible et évolutive, capables de s'adapter rapidement et efficacement aux demandes des
consommateurs modernes.
Le gain rapide de popularité qu'ont connu les microservices découle directement de ces influences
du marché. En l'espace de quelques années, les entreprises ont essayé différentes configurations
technologiques pour offrir la meilleure expérience utilisateur possible.
Défis posés par les microservices
L'un des principaux problèmes rencontrés par les entreprises envisageant de passer aux microservices
est l'inertie au changement des systèmes monoblocs existants. Les responsables IT et DevOps doivent
déterminer les modalités de l'intégration des microservices à leurs applications existantes. Cela entraîne
une façon de procéder radicalement différente. Dans leur livre blanc intitulé « Four-Tier Engagement
Platform » (Plateforme d'engagement à quatre niveaux), les auteurs de Forrester Research, Ted Schadler,
Michael Facemire et John McCarthy, expliquent que les entreprises technologiques doivent à présent
passer à une architecture à quatre niveaux.
Dans un article pour Infoworld, Patrick Nommensen a résumé ce qu'est l'architecture à quatre niveaux.
Comme il l'explique, les changements profonds que connaît le monde de l'informatique, tels que
l'impressionnante pénétration du marché des appareils mobiles, amènent les développeurs à adopter une
approche radicalement différente afin de repenser la façon dont les applications sont développées.
Avec l'approche à quatre niveaux, l'architecture est divisée en plusieurs couches :
– Niveau client : une expérience fournie par des clients mobiles et l'Internet des objets.
– Niveau prestation : Optimise l'expérience de l'utilisateur en fonction de son appareil tout en
personnalisant le contenu grâce au monitoring de ses actions.
– Niveau agrégation : Regroupe les données provenant du niveau des services tout en convertissant
leur protocole.
– Niveau services : L'ensemble des services externes, par exemple Twilio et Box, ainsi que les données,
services et systèmes d'enregistrement existant déjà en interne.
La principale différence avec cette nouvelle approche est probablement la séparation du niveau client.
Avec ce modèle, les couches inférieures sont modifiées en continu, en fonction des interactions en
temps réel avec les utilisateurs. Cette méthode est déjà utilisée par des applications majeures comme
Uber et Netflix.
Client Prestation Agrégation
Une expérience client Optimise l'expérience de Regroupe les données
fournie par des clients l'utilisateur en fonction de son provenant du niveau des
mobiles et l'Internet
des objets.
appareil tout en personnalisant
le contenu grâce au monitoring
services tout en convertissant
leur protocole.
données, services et systèmes
de ses actions.
Architecture à quatre niveaux
Figure 1 : Architecture à quatre niveaux
Chapitre 3 : La migration vers les microservices
Les outils nécessaires
Tout cela est très bien mais quels sont les outils nécessaires pour réaliser la même chose que ces
sites ? La première étape est de choisir l'architecture microservices à adopter. Vous devez comprendre
l'interaction des services avant d'essayer d'optimiser leur implémentation. Ensuite, même si les
architectures microservices vous apportent une certaine rapidité, vous devez optimiser ces gains de
vitesse en permanence. Il faut donc que vous fassiez preuve de flexibilité en choisissant les outils pour
déployer votre architecture.
Netflix développe ses propres outils
Ce qui est formidable avec les microservices, c'est que les développeurs ne sont pas obligés d'utiliser des
langages ou des frameworks internes comme Java/Spring ou Ruby on Rails. Les composants peuvent
être créés avec Ruby, Java ou JavaScript/Node. Les programmeurs peuvent continuer d'utiliser les
langages et les outils de développement qu'ils maîtrisent, qu'ils aiment et auxquels ils font confiance.
Cela renforce leur productivité et leur satisfaction au travail.
Certaines entreprises développent leurs propres outils. C'est difficile à croire aujourd'hui, mais au
début, Netflix était exécuté sur un simple fichier WAR. Netflix devait utiliser une multitude d'outils
différents, développés pour une grande part en interne lors de la conception de son environnement de
microservices. Cela a permis à la société d'être flexible et rapide. Voici certains des outils ainsi conçus :
– Slalom : un utilitaire interne qui laisse à un service déterminer ses dépendances (en amont et en
aval), le niveau de contribution à la demande du service et la santé de la requête.
– Mogul : cet utilitaire utilise des données provenant d'Atlas, le framework de monitoring de
l'entreprise, détermine les différentes corrélations entre les indicateurs de performance et choisit
ceux susceptibles de faire varier la demande sur des microservices spécifiques.
– Vector : un framework « on-instance » qui assure le monitoring des performances avec des
indicateurs de performance spécifiques sur le navigateur de chaque développeur. Netflix a ajouté son
interface utilisateur à un framework existant, appelé Performance Copilot.
Si l'entreprise a développé ces outils, c'est parce que ceux proposés sur le marché ne respectaient pas
leurs exigences en matière de systèmes. C'est un autre élément à prendre en compte si vous déployez
des microservices : les outils actuellement sur le marché répondent-ils à vos besoins et/ou devrez-vous
développer vos propres outils ?
Aspect pratique de la migration
Comment aborder la migration vers les microservices ? Owen Garret a détaillé pour InfoWorld une
approche pratique en trois étapes.
Services
1. Isolation d'un composant : choisir un composant parmi ses applications existantes et procéder à la
mise en œuvre des microservices en menant un projet pilote.
2. Collaboration : partager les techniques acquises et les leçons tirées du projet pilote de la première
étape avec les intervenants, les programmeurs et les développeurs. Cela permet de mettre tout le
L'ensemble des services
monde d'accord sur les nouveaux processus et les nouveaux projets.
externes, par exemple
Twilio et Box, ainsi que les
3. Connexion : terminer l'application et la mettre à disposition des utilisateurs en situation réelle.
d'enregistrement existant
déjà en interne.
11

Composant
Connecter Collaborer
Figure 2 : Approche en trois étapes de la migration
Couplage des données
L'architecture des microservices est souplement couplée à des données souvent transmises par API.
Il n'est pas rare qu'un microservice comprenne moins de 200 lignes de code et ne gère qu'une seule
tâche. Un couplage souple repose sur trois éléments :
1. Une portée limitée et une intelligence intégrée et dédiée.
2. Une intelligence séparée de la fonction de messagerie.
3. Une tolérance à une vaste variété de modifications de microservices ayant des fonctions similaires --
les changements ne sont pas forcés ni coordonnés.
Les API traduisent une caractéristique établissant un contrat qui spécifie le service assuré et l'utilisation
que sont censés en faire les autres programmes. Utiliser des API pour découpler les services offre un
degré exceptionnel de liberté et de flexibilité.
Nouvelles plateformes de service
Les plateformes de microservices évoluent rapidement. De nouvelles plateformes apparaissent tandis
que des plateformes plus solidement établies sont refondues. Quelques exemples :
– Azure BizTalk Microservices de Microsoft permet aux clients utilisant Azure de développer des
applications microservices dans le cloud de leur choix. Cela s'inscrit dans un projet plus vaste pour
déplacer Azure vers un modèle de petits composants.
– Gilliam est une plateforme en tant que service (PaaS) personnalisée pour créer, déployer et faire
évoluer les microservices. Elle crée une image Docker de chaque référentiel de code sur site.
Chapitre 3 : La migration vers les microservices
– LSQ est une PaaS avec des modèles préconfigurés, un éditeur de documents et le gestionnaire
de paquets NPM. Elle comprend un environnement de développement, une zone de tests et
d'assemblage et le déploiement dans le cloud.
– Pivotal est une plateforme « native cloud » principalement conçue pour le développement de
microservices pour des entreprises comme Ford, Allstate, Mercedes-Benz, GE, Humana et Comcast.
Open source
Comme Allen Naim, responsable produits de Kubernetes, l'a expliqué lors d'un panel à l'AppSphere
15, de nombreux composants pour les microservices sont open source. Cela simplifie beaucoup leur
fonctionnement commun et le retour sur investissement est bien meilleur qu'avec l'architecture orientée
services (SOA). Chris Morgan, directeur de gestion de produit pour l'écosystème de partenaires OpenShift
de Red Hat, est d'acoord sur ce point. Red Hat s'appuie sur l'open source dès le début et M. Morgan s'est
réjoui du fait que de nombreux microservices sont en open source. D'anciens rivaux qui n'auraient jamais
partagé des idées ou du code travaillent désormais ensemble tous les jours. Il a précisé que Red Hat était
même devenu ami avec Microsoft, ce qu'il n'aurait pas pu dire il y a encore quelques années.
Exemples
Quels sont les exemples d'entreprises utilisant des microservices aujourd'hui ? Parmi elles :
– Netflix : comme nous l'avons expliqué précédemment, Netflix est rapidement passée d'un simple
fichier WAR à une utilisation intensive des microservices.
– The Guardian : d'après Martin Fowler, dans son article de référence intitulé « Microservices - a
definition of this new architectural term » (Microservices : une définition de ce nouveau terme
d'architecture), le site Web du journal The Guardian est un excellent exemple d'une entreprise ayant
fait évolué son architecture monobloc grâce aux microservices. Son système monobloc central est
maintenu mais utilise des microservices pour ajouter de nouveaux composants grâce à l'API du
monobloc. Cette approche est particulièrement adaptée aux pages temporairement ajoutées sur le
site Internet, comme celles sur des événements spéciaux.
– Gilt Groupe : Gilt, site d'e-commerce, utilise une architecture microservices massive avec
plusieurs équipes distinctes travaillant sur différents services en même temps. L'un des importants
changements entrepris par ce groupe a été de remplacer l'équipe dédiée à l'architecture par des
ingénieurs répartis dans différentes équipes pour décider de l'architecture.
Microservices au service des applications existantes
Imaginez un système existant codé en C et fonctionnant sur plusieurs unités centrales. II fonctionne
depuis des années sans aucun incident majeur et assure le cœur de compétences de l'entreprise de
façon fiable. Faudrait-il essayer de réécrire le code pour intégrer de nouvelles fonctionnalités ? Il est
conseillé d'adopter une approche progressive, car on peut rapidement tester les nouveaux microservices
sans affecter la fiabilité de la structure monobloc existante. On peut facilement utiliser les microservices
pour créer de nouvelles fonctionnalités en utilisant l'API existante. Une autre approche consiste à rendre
l'architecture monobloc modulaire pour qu'elle puisse continuer avec le même code et des déploiements
communs, mais en déplaçant les modules vers des microservices autonomes si besoin.
Boris Scholl, chef de projet principal pour Azure Compute chez Microsoft, a déclaré lors du panel organisé
à l'Appsphere 15 que Microsoft utilisait deux approches. Azure est une plateforme totalement ouverte
capable d'exécuter presque tout, y compris des systèmes rivaux comme Red Hat et Kubernetes. De plus,
Azure Service Fabric ajoute une couche supplémentaire qui fournit une gestion et une orchestration
rapides, avec des acteurs et un recueil fiables.
12

Personnel et processus
Le déploiement des microservices ne se résume pas à l'intégration d'une nouvelle technologie. Il faut
adopter de nouveaux processus et créer de nouvelles dynamiques de groupe pour que la transition
soit efficace à long terme. Souvent, les responsables décomposent les applications par technologie
et attribuent des responsabilités aux différentes équipes. Avec les microservices, les applications sont
réparties en services regroupés selon leur fonction dans l'activité. Tous les éléments des applications
comme l'expérience utilisateur, les connexions externes et le stockage sont mis en œuvre dans
chaque domaine d'activité. Les membres de chaque équipe s'occupent du développement complet de
l'application, en couvrant aussi bien les interfaces utilisateur que les bases de données.
Ce changement structurel a un impact sur le personnel. Pour les développeurs habitués aux systèmes
monoblocs, passer d'un environnement à un seul langage à un monde de nouvelles technologies à
plusieurs langages peut être délicat. Les microservices leur donnent plus de liberté, d'autonomie et de
responsabilité sur le service dans sa globalité.
Cette plus grande liberté soudainement acquise peut désorienter les programmeurs ayant une
expérience de plusieurs années dans les méthodes traditionnelles. Vous devez pouvoir évaluer en
permanence la capacité d'adaptation de votre équipe. Certaines personnes ont peut-être besoin de
temps pour s'habituer aux nouvelles directives et procédures. Savoir communiquer clairement est
essentiel. Expliquez précisément à chacun ses responsabilités dans cette nouvelle approche de travail
et l'importance du rôle qu'il tient. À moins d'obtenir l'adhésion de votre équipe dès le départ, faire des
ajustements par la suite risque, au mieux, d'être difficile et au pire, de mener à l'échec.
Chapitre 3 : La migration vers les microservices
Une nouvelle ère informatique
Nous entrons dans une nouvelle ère informatique caractérisée par un traitement ultra-rapide des
données. Les événements font l'objet d'un monitoring, d'une analyse et d'un traitement dès qu'ils se
produisent. Des décisions rapides peuvent être prises sur la base de ce flux de données actualisé en
permanence. Cela apporte de meilleurs services aux clients, des opérations améliorées et un monitoring
instantané des performances de l'entreprise par rapport à des objectifs prédéterminés.
Les microservices ne sont pas la panacée. Ils peuvent aussi présenter des inconvénients : une duplication
du code, une non-concordance des interfaces, un délai du traitement des opérations et la difficulté à
tester plusieurs systèmes en continu. Toutefois, la création de composants faiblement couplés par des
équipes indépendantes utilisant différents langages et outils présente des avantages qui compensent
largement ces inconvénients. Dans notre environnement informatique actuel, vitesse et flexibilité sont les
clés du succès. Et les microservices assurent justement les deux.
13
Chapitre 4 : L
 es défis liés à la visibilité
et au monitoring

Les entreprises qui décident de passer à une architecture microservices sont confrontées à des défis
importants. Cette section examine certains des obstacles que l'on peut rencontrer, explique comment
d'autres entreprises les surmontent et pourquoi vos efforts seront bénéfiques.
Architecture microservices
L'architecture microservices est bien plus complexe que les systèmes classiques. En fait, l'environnement
se complexifie car il faut gérer et soutenir une multitude d'éléments en mouvement. Il faut être
particulièrement vigilant sur plusieurs points, notamment :
– À mesure qu'on ajoute des microservices, il faut s'assurer qu'ils peuvent évoluer ensemble. Avec la
granularité plus large, le nombre d'éléments en mouvement est plus important, ce qui augmente la
complexité.
– Plus il y a de services en interaction, plus les points de défaillance potentielle sont nombreux. Les
développeurs les plus ingénieux s'arrangent pour garder une longueur d'avance et anticiper les
défaillances.
– Transformer des fonctions d'une application monobloc aux microservices génère de nombreux petits
composants en communication permanente. Retracer l'origine des problèmes de performances à
travers plusieurs niveaux pour une seule transaction peut s'avérer difficile. Cela peut se résoudre en
corrélant les appels avec différentes méthodes telles que les en-têtes personnalisés, les jetons ou les
identifiants.
– Le logging classique ne convient pas aux microservices car ils sont distribués, indépendants et n’ont
pas d’état : l'identification du problème produirait un trop grand nombre de logs. Le logging doit
pouvoir corréler les événements sur différentes plateformes.
Il faut également tenir compte des points suivants :
1. Opérations et infrastructure : Les équipes de développement doivent collaborer plus étroitement
que jamais avec les équipes opérationnelles. Sinon, vous risqueriez de perdre le contrôle de la
situation à cause de la multitude d'opérations effectuées simultanément.
2. Prise en charge : Il est beaucoup plus difficile de gérer et de maintenir une configuration en
microservices qu'une application monobloc. En effet, chaque microservice peut être constitué d'une
large variété de frameworks et de langages. Cette extrême complexité de prise en charge pèse
lourdement sur les décisions d'ajout de nouveaux services. Si un membre de l'équipe veut créer un
nouveau service dans un langage ésotérique, cela affecte le reste de l'équipe car il faut s'assurer que
ce service pourra fonctionner dans le système existant.
3. Monitoring : Lorsque vous ajoutez de nouveaux services, il est plus difficile de configurer et d'assurer
leur monitoring. Il faut s'appuyer sur l'automatisation pour s'assurer que le monitoring peut suivre le
rythme des évolutions des services.
4. Sécurité des applications : La multitude des services dans cette architecture crée davantage de
cibles faciles pour les pirates et autres personnes malintentionnées. Étant donné que plusieurs
systèmes d'exploitation, frameworks et langages sont à surveiller, le groupe chargé de la sécurité est
totalement accaparé par sa tâche de veiller à l'invulnérabilité du système.
5. Requêtes : Un moyen de transmettre des données entre les services est d'utiliser des en-têtes
de requête. Les en-têtes de requête peuvent contenir des données spécifiques (p. ex. celles
d'authentification) qui réduisent le nombre de requêtes nécessaires. Cependant, quand cela se
produit avec d'innombrables services, il peut être nécessaire de renforcer la coordination avec les
membres des autres équipes.
6. Mise en cache : La mise en cache permet de réduire le nombre de requêtes nécessaires. La mise
en cache de requêtes qui impliquent une multitude de services peut vite devenir compliquée
et nécessiter une meilleure communication entre les différents services et leurs équipes de
développement.
Chapitre 4 : Les défis liés à la visibilité et la surveillance
7. Tolérance aux erreurs : Avec les microservices, le mot d'ordre est « interdépendance ». Les services
doivent être capables de supporter les pannes et les délais inexplicables. Les pannes peuvent
rapidement se multiplier et provoquer une réaction en chaîne dans plusieurs services, ainsi qu'un pic
inutile dans l'utilisation des services. La tolérance aux erreurs dans cet environnement est beaucoup
plus complexe que dans un système monobloc.
Spécialistes des monoblocs
Quand Phil Calçado travaillait chez SoundCloud, l'une des difficultés rencontrées dans la migration vers
les microservices était que le codebase du système monobloc était devenu si volumineux et si complexe
que personne ne le comprenait totalement. Les membres de l'équipe qui maîtrisaient les différentes
sections sont alors devenus, en pratique, des experts de leurs domaines de compétence respectifs. Les
autres devaient attendre que les spécialistes internes soient disponibles pour effectuer des modifications.
Cela leur faisait perdre beaucoup de temps, en plus d'être fastidieux.
Le personnel travaillant sur les microservices était si nombreux qu'il n'y avait pas assez de monde pour
vérifier les modifications. Cet exemple permet de comprendre pourquoi, avec les microservices, les
problèmes liés au personnel sont au moins aussi complexes et difficiles à résoudre que les difficultés liées
au code et à la technologie.
Isoler les composants, collaborer et connecter
Owen Garrett a rédigé un essai pour Infoworld en juin 2015 dans lequel il a défini les trois différentes
étapes du déploiement des microservices : isoler les composants, collaborer et connecter.
1. Isoler un composant : Généralement, lors de cette étape, les ingénieurs choisissent le projet pilote
de nouvelle technologie qu'ils souhaitent mener. La même approche peut être adoptée pour la mise
en œuvre des microservices. Travailler avec des projets pilotes vous permet de découvrir de nouvelles
méthodes de travail et les nouvelles technologies. Il faut vous fixer des objectifs adaptés à vos
besoins actuels tout en gardant à l'esprit que des difficultés se présenteront. L'avantage est que vous
pourrez utiliser les retours négatifs lors de la création de nouveaux projets.
Choisissez une partie d'une application monobloc que vous pensez pouvoir assez facilement migrer
vers un microservice. Créez une API pour accéder à ce service, puis construisez un microservice.
En utilisant les outils que vos ingénieurs maîtrisent, vous devez être en mesure de créer un
microservice que vous pouvez développer, tester et déployer. Vous commencerez à développer
un système de service continu que vous pourrez modifier et ajuster.
2. Collaborer : La résolution des problèmes techniques est un des facteurs. Par exemple, le logging
classique rend plus difficile l'identification des causes des problèmes de performance. Cependant,
l'objectif plus général du processus de transition est d'assurer une collaboration efficace entre les
membres de l'équipe. Les connaissances acquises pendant le projet pilote doivent être partagées
avec tout le personnel impliqué dans le développement. Cela vous permet de vous assurer que le
processus convient à tout le monde. De plus, leur adhésion sera plus facile à obtenir lorsque vous
élargirez le développement des microservices.
Chaque équipe doit disposer de toutes les compétences nécessaires pour créer un service.
Cela inclut les compétences relatives aux données, à la présentation et à la logique - du début
à la fin. La collaboration se résume au partage de références technologiques et d'API.
3. Connecter : Créer les différents composants d'un microservice n'est que le début. Ils doivent être
connectés et une application complète doit être présentée aux utilisateurs. Les microservices
sont ainsi plus flexibles et plus adaptables que les approches précédentes, comme par exemple
l'architecture orientée services (SOA).
15
 Chapitre 4 : Les défis liés à la visibilité et la surveillance

Développement sous les projecteurs Démarrer la transition

Dans un développement classique, l'intégration des différentes fonctions au sein du service IT était peu
importante. L'approche DevOps fait évoluer la collaboration en rapprochant les équipes opérationnelles,
de développement et d'assurance qualité et en favorisant leur communication durant l'intégralité du
processus de développement des applications.
L'approche DevOps n'est pas une simple responsabilité endossée par une personne ou un groupe
d'individus. Elle permet plutôt de conceptualiser la structure nécessaire à une coopération étroite
entre les forces opérationnelles et celles de développement. Dans une architecture microservices,
les développeurs ont la responsabilité de créer un système délivrant avec succès le produit final.
Une fois le processus de transition amorcé, vous serez amené à vous poser des questions inattendues,
notamment :
– Quelle charge de travail doit-on déplacer vers les microservices ?
– Faut-il permettre la migration du code vers différents services ?
– Comment déterminer le périmètre de chaque microservice en fonctionnement ?
– Comment assurer le monitoring des performances des microservices ?

Le développement doit évoluer

À la manière des entreprises de toutes tailles qui passent progressivement aux microservices,
le développement doit évoluer. Étant donnée la simplicité du déploiement des microservices,
les développeurs sont désormais impliqués dans le déploiement du code et le monitoring de la
production. On est bien loin des situations classiques dans lesquelles les développeurs écrivaient le code
et le « balançaient de l'autre côté » à une autre équipe (DevOps) qui s'occupait du déploiement et de la
maintenance. Aujourd'hui, les développeurs et les équipes DevOps sont réunis au sein de plus petites
équipes dédiées aux applications et responsables de trois missions principales : le développement,
le déploiement et le monitoring.

Les microservices changent la structure des équipes, permettant ainsi aux entreprises de créer des
équipes focalisées sur des services particuliers disposant de plus d'autonomie et de responsabilité
dans un domaine bien délimité. Grâce à cette approche, l'entreprise peut réagir plus rapidement aux
fluctuations de la demande, sans interrompre ses activités principales. Cela permet également d'intégrer
plus rapidement de nouveaux employés.

Les équipes de développement risquent d'être confrontées à de nouveaux défis, notamment :

– Une pénurie de développeurs avec de l'expérience en JavaScript et sachant créer des architectures
microservices.
– La compréhension et la mise en œuvre de services pour l'Internet des objets.
– La capacité d'aider les entreprises à introduire la technologie dans la stratégie et la planification des
activités.
– Éclairer les dirigeants d'entreprise sur l'apport des API ouvertes pour développer leurs activités et
susciter de nouvelles opportunités sur le marché.
– Moyen de simplifier le stack de développement, choisir la bonne technologie et rejeter les offres des
fournisseurs proposant des intergiciels peu efficaces.
– Étudier les leaders du secteur comme Netflix et déterminer les implémentations de microservices qui
leur seront les plus bénéfiques.
– Comprendre que de nombreux fournisseurs n'ont pas encore mis au point de plateforme de
microservices stable.
– Supporter la pression associée à la gestion et à l'exécution simultanées d’une centaine de
microservices autonomes.
– Gérer un réseau de plus en plus complexe regroupant des équipes opérationnelles, des architectes,
des programmeurs, du personnel d'assurance qualité et des intégrateurs qui ne maîtrisent peut-être
pas encore totalement l'approche des microservices.

16
appdynamics.com
© 2016 Copyright AppDynamics