SOA, microservices, AP1 management (Fournier-Morel, Grojean, Plouin, Rognon) (Z-Library)

📄 File Format: PDF

💾 File Size: 18.5 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

Xavier Fournier-Morel Pascal Grojean Guillaume Plouin Cyril Rogon 5e édition SOA MICROSERVICES, API MANAGEMENT Le guide de l’architecture d’un SI agile

📄 Page 2

© Dunod, 2020 11 rue Paul Bert, 92240 Malakoff www.dunod.com ISBN 978‑2‑10‑081356‑8 Image de couverture : © ThomasSereda, iStock

📄 Page 3

Table des matières Avant-propos ................................................................................................................................................... IX Préface .................................................................................................................................................................. XV Partie 1 Le cahier des charges des SI agiles 1 Accepter l’entropie des systèmes d’information ............................................................ 3 1.1 Une brève histoire de l’informatique .............................................................................. 3 1.2 La transformation digitale et ses conséquences sur le SI ................................ 8 2 Définir le cahier des charges du style SOA ........................................................................ 13 2.1 Les besoins des métiers ....................................................................................................... 13 2.2 Les exigences techniques .................................................................................................... 20 Partie 2 Concepts & styles SOA 3 Urbaniser avec une architecture SOA .................................................................................... 41 3.1 Les monolithes logiciels : un peu de (pré)histoire .................................................. 42 3.2 Les architectures de services ............................................................................................. 44 3.3 Quelques caractéristiques clés d’une SOA ................................................................ 57 3.4 Quelques idées reçues sur SOA ....................................................................................... 62 3.5 Conclusion ...................................................................................................................................... 64 4 Utiliser les concepts de service et d’API ............................................................................... 67 4.1 Formaliser les services ........................................................................................................... 67 4.2 Spécifier un contrat de service .......................................................................................... 70 4.3 Mettre en production et exploiter les services ........................................................ 75 4.4 Cycles d’API et de services .................................................................................................. 79 4.5 Pour une description formelle explicite du contrat de service ........................ 80 5 Faire émerger une plate-forme SOA ........................................................................................ 85 5.1 L’émergence des gestionnaires d’API ............................................................................ 85 5.2 Quelle utilité pour un bus de service ? .......................................................................... 90 5.3 Vers la plate‑forme SOA ......................................................................................................... 94 5.4 Une chaîne continue pour SOA ......................................................................................... 100 Partie 3 Méthodologie SOA 6 Décrire la cible .......................................................................................................................................... 107 6.1 Présentation du cas d’école ................................................................................................ 107 6.2 L’architecture de référence SOA 3.0 ............................................................................... 115 1

📄 Page 4

Table des matièresVI 7 Identifier et modéliser les services SOA............................................................................... 123 7.1 Architecture de services : les questions clés ............................................................ 123 7.2 Mais où sont les services ? les approches possibles ........................................... 126 7.3 L’approche mondes métiers ................................................................................................. 128 7.4 Autonomie ou indépendance ? le dialogue entre les mondes ........................ 135 7.5 L’Impact des contraintes de performance et de robustesse – le pattern CQRS ............................................................................... 139 7.6 De l’identification à la modélisation ................................................................................ 145 7.7 Anti‑patterns .................................................................................................................................. 149 8 Modéliser une SOA réactive .......................................................................................................... 155 8.1 Définition d’une architecture réactive ............................................................................ 155 8.2 Exigences d’une architecture réactive........................................................................... 158 8.3 Les principes techniques d’une architecture réactive .......................................... 160 8.4 Patterns de structuration d’une architecture SOA réactive ............................... 166 8.5 L’exemple de l’architecture fil rouge ............................................................................... 172 8.6 Les caractéristiques d’un middleware orienté flots d’événements ............. 175 9 Modéliser les processus métiers ......................................................................................................................... 181 9.1 Un bref rappel sur les événements métiers ............................................................ 181 9.2 Qu’est‑ce qu’un processus SOA ? ................................................................................... 183 9.3 Modéliser les processus métiers BPM : les étapes clés ................................... 186 9.4 Modéliser une architecture BPM dans un cadre SOA ......................................... 191 9.5 Modéliser une architecture ACM dans un cadre SOA ......................................... 197 9.6 Combiner les approches processus ................................................................................ 201 10 Modéliser les applications composites interactives.................................................... 203 10.1 Le modèle MVC .......................................................................................................................... 203 10.2 MVC doit évoluer ........................................................................................................................ 205 10.3 MVC + SOA : le modèle MVVM et ses limites ......................................................... 209 10.4 Le concept de contexte local .............................................................................................. 212 10.5 Concept de transaction longue SOA .............................................................................. 218 10.6 Intégrer MVC et SOA : de nouveaux outils ................................................................. 221 10.7 Le modèle MVC revisité ......................................................................................................... 225 Partie 4 SOA et architecture d’entreprise 11 Bâtir une architecture d’entreprise avec SOA .................................................................. 231 11.1 Position du problème ............................................................................................................... 231 11.2 Le point de vue architecture métier ................................................................................ 234 11.3 Le point de vue architecture logique .............................................................................. 238 11.4 Le point de vue architecture technique......................................................................... 240 10 11

📄 Page 5

Table des matières VII 11.5 Le point de vue architecture physique .......................................................................... 241 11.6 Le point de vue architecture opérationnelle ............................................................... 242 11.7 La cohérence entre les points de vue ........................................................................... 243 11.8 La nécessité d’une méthode .............................................................................................. 244 12 Diriger la gouvernance d’une SOA ............................................................................................ 251 12.1 Gouvernance et prise en compte de SOA .................................................................. 251 12.2 Démarche de gouvernance SOA ....................................................................................... 254 Partie 5 Robustesse et performance des services 13 Concevoir une SOA robuste .......................................................................................................... 275 13.1 Introduction : robustesse et SOA...................................................................................... 275 13.2 Les trois politiques de redondance ................................................................................. 279 13.3 La redondance simple des services SOA .................................................................... 280 13.4 La redondance des services « à état » .......................................................................... 283 14 Concevoir une SOA performante ............................................................................................... 297 14.1 Introduction : performance et SOA .................................................................................. 297 14.2 Scalabilité par les opérations ............................................................................................... 300 14.3 Scalabilité par les données ................................................................................................... 306 14.4 Scalabilité par les fonctions.................................................................................................. 310 14.5 Élasticité de l’architecture ..................................................................................................... 310 15 Comprendre les enjeux d’une SOA distribuée ................................................................. 315 15.1 Position du problème ............................................................................................................... 316 15.2 Robustesse et défaillance matérielle ............................................................................. 317 15.3 Le théorème PAC ....................................................................................................................... 321 15.4 Performance et cohérence à terme ................................................................................ 326 15.5 Robustesse et cohérence avec quorum....................................................................... 331 15.6 Cohérence forte et acid distribué ..................................................................................... 333 15.7 Bilan sur les pistes proposées d’amélioration .......................................................... 338 Partie 6 Monter en puissance sur SOA, microservices et API ouvertes 16 Concevoir API et services ................................................................................................................ 343 16.1 Concevoir des API utilisables ............................................................................................ 343 16.2 Implémenter une api et le service associé................................................................. 353 17 Concevoir un service performant et robuste .................................................................... 367 17.1 Les types de service ................................................................................................................ 368 17.2 Présentation de l’anatomie d’un service ..................................................................... 369 17.3 Le pattern « lecteur tolérant » ............................................................................................. 371 17.4 Le pattern « fusible »................................................................................................................. 373 12 13 14 15 16 17

📄 Page 6

Table des matièresVIII 17.5 Le pattern « registre » .............................................................................................................. 377 17.6 Le modèle d’exécution d’un (micro)service ............................................................... 378 17.7 Le pattern « redémarrage à chaud » ................................................................................ 386 18 Mettre en œuvre une infrastructure SOA ............................................................................ 391 18.1 Choisir les socles de l’architecture .................................................................................. 391 19 Déployer les services .......................................................................................................................... 405 19.1 Introduction aux conteneurs ............................................................................................... 405 19.2 Retour sur les principes ......................................................................................................... 412 19. 3 Vers de véritables patterns de déploiement .................................................................... 417 19.4 Bilan : faut‑il des services de conteneur ? .................................................................... 421 20 Sécuriser les services ......................................................................................................................... 423 20.1 Sécuriser les services ............................................................................................................. 423 20.2 L’authentification vis‑à‑vis d’une API .............................................................................. 428 20.3 L’autorisation d’accès à des ressources ....................................................................... 432 20.4 Le provisioning des accédants ........................................................................................... 435 20.5 Méthodes cryptographiques dédiées au monde des services ...................... 437 21 Gérer les API .............................................................................................................................................. 439 21.1 Les besoins de la gestion d’API ......................................................................................... 439 21.2 Outiller la gestion d’API........................................................................................................... 440 21.3 Innover avec les API ................................................................................................................. 448 21.4 Mettre en œuvre les API........................................................................................................ 450 21.5 Quel impact de la gestion d’API sur le SI ? .................................................................. 463 Partie 7 Choisir son parcours SOA 22 Aller vers SOA 3.0 .................................................................................................................................. 473 22.1 La rénovation du système d’information classique ............................................... 474 22.2 La mise en place du système d’information SOA réactive ............................... 487 Index ...................................................................................................................................................................... 497 18 19 0 1 2

📄 Page 7

Avant-propos Il y a 10 ans, on présentait les architectures de services, dites SOA, comme une solu‑ tion formidable pour mettre fin aux problématiques d’intégration entre applications hétérogènes. SOA devait aussi rendre les systèmes d’information plus adaptables et plus agiles. SOA a initialement déçu certaines entreprises car les grands éditeurs ont proposé des solutions « tout en un », capables de gérer l’ensemble des problématiques d’intégration, au travers d’une plate‑forme technique, généralement onéreuse car complexe, et vendue via un discours du type : « achetez d’abord l’outil et SOA viendra après sans effort ». De leur côté, les géants du Web (Google, Amazon, Facebook…) n’ont gardé de SOA que quelques patterns d’architecture qu’ils ont appliqués de manière pragmatique, au travers d’architectures simples, basées sur les technologies du Web. Ils ont ainsi su bâtir des systèmes d’information parmi les plus exigeants en termes de performance en se basant sur des architectures de services. Ils ont réussi tout au long des dix dernières années là où d’autres ont échoué. L’expérience des géants du Web démontre la pertinence des architectures de services, mais elle démontre aussi l’agilité que peuvent offrir ces architectures, en permettant de transformer un SI à un rythme très rapide. C’est d’ailleurs cette rapi‑ dité qui est au cœur de la disruption de nombreux secteurs d’activité (taxis avec Uber, hôtellerie avec Airbnb, etc.). Il faut néanmoins noter que si les géants du Web gèrent des volumes colossaux d’utilisateurs, de données et de requêtes, leurs règles métiers sont plus simples que celles des contrats d’assurance ou celles des systèmes de yield management des compagnies aériennes. Il est donc nécessaire de prendre du recul et d’adapter leurs patterns d’architecture au contexte des entreprises dotée d’un SI existant et complexe. Le propos de cet ouvrage est donc de présenter d’une part les concepts, les méthodes, les technologies et les patterns qui permettent aujourd’hui de planifier, construire et maintenir une architecture de services opérationnelle en entreprise. On abordera en particulier les microservices, les architectures réactives, les gestion‑ naires d’API. Les auteurs, qui ont plus de 25 ans d’expérience dans les architectures informatiques, gardent ici un œil critique sur les nouvelles technologies trop souvent présentées comme révolutionnaires, et choisissent de donner un éclairage sur ce qui est à prendre et à laisser dans ces architectures pour un contexte d’entreprise. ‹ Première partie – Le cahier des charges des SI agiles L’objectif de cette première partie est d’introduire les problématiques de rationalisa‑ tion des systèmes d’information et la tension créée par la transformation digitale.

📄 Page 8

Avant-proposX Elle présente tout d’abord un historique de l’évolution des systèmes d’information et montre comment ces derniers sont souvent complexes et peu cohérents. Elle évoque ensuite le besoin d’« agilité » des SI dans le contexte actuel de disruption générale liée à la digitalisation du monde1. Enfin, elle aborde les exigences métiers et techniques que l’on peut attendre d’une nouvelle démarche d’organisation et d’intégration du SI, que ce soit dans le cas d’une volonté d’innovation ou de meilleure maîtrise de celui‑ci. La suite de l’ouvrage montrera comment SOA répond à ces exigences. Cette partie introductive est accessible à tous les profils : maîtrises d’œuvre comme maîtrises d’ouvrage. ‹ Seconde partie – Les concepts & l’approche SOA L’objectif de cette deuxième partie est de clarifier les concepts utilisés, en commençant par la notion de services et d’architecture de services, puis en introduisant le concept de microservices. Elle présente une architecture de référence positionnant les différents concepts ainsi que l’évolution de leur maturité à travers trois générations du style SOA. Elle clarifie également pourquoi les Web Services sont utiles, mais pas indispensables. Elle s’attache à décrire les fondements du concept de service et notamment la notion de contrat et de messages. Enfin, elle introduit les socles qui peuvent être mis en place de façon progressive en regard de l’architecture SOA de référence, notamment les socles de services et d’in‑ tégration. On y aborde en particulier l’émergence des gestionnaires d’API, concept clé des expositions de service et d’API et outil qui facilite l’innovation au sein d’un SI. L’utilité et la complémentarité des socles tels que le bus de services, le gestionnaire de flots d’événements, le gestionnaire de processus ou le référentiel de gouvernance des services sont également démystifiés. Cette partie est conceptuelle. Elle est accessible à tous les profils de maîtrises d’œuvre, mais aussi aux maîtrises d’ouvrage qui désirent appréhender en profondeur les architectures fonctionnelles réalisables avec SOA. ‹ Troisième partie – Méthodologie SOA La partie 3 présente les principaux aspects méthodologiques de l’approche SOA avec deux points de vue complémentaires : le métier et la technique. 1. “Software is eating the World”, selon Marc Andreessen, ancien patron de Netscape.

📄 Page 9

Avant-propos XI Cette partie traite d’abord de l’identification d’un périmètre pour SOA et des services candidats en utilisant l’exemple d’une entreprise fictive, Fil Rouge. Vient ensuite la modélisation des services et de l’architecture. Elle présente la manière de traiter aussi bien la définition classique d’un service par requête‑réponse, d’un microservice asynchrone que celle de services liés aux objets connectés via des flots d’événe‑ ments à fortes contraintes de « réactivité ». Cette modélisation s’appuie sur la présen‑ tation de patterns architecturaux que l’on considère comme éprouvés sur le terrain. Elle aborde ensuite la modélisation des processus métier, l’adoption de SOA par les entreprises étant en grande partie liée à la volonté de mettre en place de nouveaux processus métier plus électroniques. Enfin, le chapitre sur la modélisation des appli‑ cations interactives propose d’étudier l’impact de SOA sur le classique modèle MVC et ses variantes. Cette partie méthodologique vise les architectes et responsables de solutions. ‹ Quatrième partie – SOA & architecture d’entreprise Le recours aux architectures de services apporte des réponses bien au‑delà d’un seul projet ou même d’une seule solution multi‑applicatives de l’entreprise. C’est là une de ses plus grandes forces. Les initiatives raisonnant à l’échelle des points de vue de toutes les parties prenantes du SI (stratégie, métier, technique, opération‑ nel, voire clients) apparaissent aujourd’hui comme une clé de construction cohérente d’une architecture à l’échelle de l’entreprise. Plusieurs cadres de description comme Zachman, TOGAF, DODAF, NAF, etc. se proposent pour standardiser un panel plus ou moins large de ces points de vue. Pourtant, il est intéressant de comprendre pour‑ quoi tous portent progressivement leur attention sur SOA pour servir de liant ou de catalyseur à la mise en cohérence des éléments à construire et aligner au sein de l’entreprise (performance, processus métiers, modèle des données de référence, solutions applicatives, paquetage de logiciels, ressources d’infrastructure, etc.). Les outils de construction et de gouvernance à l’échelle de l’entreprise apparaissent pour supporter cette structuration, via l’analyse et le suivi du fonctionnement et des transformations propres à chaque entreprise. L’approche SOA permet alors de fournir la colonne vertébrale d’un référentiel unifié de cette organisation. Cette partie organisationnelle et le cadre de démarche s’adressent aux architectes d’entre- prise, responsables de lignes métiers ou de directions informatiques. ‹ Cinquième partie – Robustesse et performance SOA L’émergence des microservices met en évidence le caractère de plus en plus distribué du système d’information. Sa robustesse et sa performance deviennent des points

📄 Page 10

Avant-proposXII clés non seulement pour les directions de la production des DSI, mais aussi pour les architectes et les développeurs impliqués dans une démarche DevOps. Il n’est plus question pour aucune direction de rejeter ces problématiques « vers l’autre » ou « à plus tard » dans un monde dont le système nerveux devient digital. Ces exigences de robustesse et de performance ne sont pas triviales à satisfaire, en particulier pour les services dits « à état » (stateful). L’exigence de robustesse d’un service est présentée dans cette partie comme la capacité technique de ce service à être disponible sans interruption. L’exigence de performance est quant à elle abordée comme la capacité technique de ce service à absorber une charge de travail pouvant varier fortement. Cette partie présente alors les différentes solutions possibles pour satisfaire ces exigences. Elle propose également une réflexion sur les probléma‑ tiques techniques au cœur de ces solutions, en particulier le fameux théorème CAP et ses conséquences sur la réplication des données, la tolérance aux pannes réseau et la cohérence des transactions. La compréhension de ces problématiques est indis‑ pensable pour effectuer son choix parmi les outils de plus en plus nombreux dans ce domaine, puis pour déployer et configurer ces outils. Cette partie s’adresse aux architectes techniques aussi bien qu’aux développeurs et aux responsables de la production soucieux de travailler ensemble pour garantir le bon fonction- nement des services soumis à de plus en plus fortes contraintes. ‹ Sixième partie – Monter en puissance sur SOA, microservices et gestion d’API On aborde ici les aspects techniques de la mise en pratique des architectures de services : les normes, langages, technologies, outils et bonnes pratiques qui sous‑ tendent tout le cycle de réalisation de services et microservices, depuis la conception, le développement, le déploiement jusqu’à la sécurisation et la gestion de l’exploita‑ tion d’interfaces publiques, en passant par le recours à des socles d’infrastructure pour industrialiser les mises en œuvre SOA. Cette partie s’adresse aux équipes de réalisation, concepteurs, développeurs, architectes techniques et responsables d’exploitation de services. ‹ Septième partie – Choisir son parcours SOA Une démarche vers SOA ne part jamais de zéro, d’autant que nombre d’entreprises ont débuté une démarche SOA 1.0 il y a quelques années. En fonction de la situation du SI de l’entreprise, cette partie propose un cheminement pragmatique, selon des étapes et jalons clés, évitant le syndrome du mur infranchissable et du Big bang explosif.

📄 Page 11

Avant-propos XIII Cette partie est destinée avant tout aux directions informatiques et aux responsables de projet. ‹ Compléments sur le Web Les auteurs souhaitaient ajouter quelques extensions à cet ouvrage, sans le rendre trop volumineux : des exemples de codes pratiques et informations complémen‑ taires. Pour faciliter leur mise à jour régulière, ces éléments sont rendus dispo‑ nibles sur le Web à l’adresse https://www.dunod.com/sciences‑techniques/ soa‑microservices‑et‑api‑management. ‹ Remerciements Les auteurs tiennent après leur quatrième édition de cet ouvrage à remercier une nouvelle fois, et encore plus chaleureusement leurs compagnes pour leur immense patience et soutien pendant les périodes de rédaction et remise à jour de ce livre. Leur reconnaissance va aussi à leurs entreprises respectives qui ont choisi de spon‑ soriser et rendre possible cette nouvelle édition de l’ouvrage. Enfin, ils remercient très vivement leurs collègues et amis qui ont bien voulu relire le manuscrit initial et les faire bénéficier de remarques ou contacts pertinents, en parti‑ culier, Monsieur Claudio Parnenzini, urbaniste visionnaire en charge des Systèmes d’information de l’État de Fribourg (Suisse), Monsieur Dominique Debailleux, archi‑ tecte senior SOA enthousiaste chez Emoxa et Monsieur Damien Engrand, architecte technique SOA chevronné et consultant chez Emoxa (France).

📄 Page 12

(This page has no text content)

📄 Page 13

Préface L’architecture orientée‑service, plus connue sous le nom de SOA selon l’acronyme anglais, est une expression incontournable dans le monde des systèmes d’informa‑ tion depuis le début des années 2000. Il existe quelques bons livres, dont celui‑ci, qui expliquent ce qu’est SOA : SOA est une approche fondamentale pour maitriser le système d’information. En revanche, je ne connais pas d’autres livres qui expliquent le « comment déployer SOA » avec autant de pertinence, de précision et de talent. C’est pourquoi j’avais fait de ce livre une des pierres angulaires du cours « Théorie et pratique du système d’information » que je donnais à l’Ecole Polytechnique il y a quelques années. Voici une nouvelle édition en 2017 qui a suivi les changements majeurs des dernières années, liés à l’accélération du temps métier. Les systèmes d’information d’au‑ jourd’hui, en particulier dans leur partie « digitale », sont en mouvement perpétuel et le code n’est plus un composant stable de leur fabrication, mais un flux permanent. Les frontières doivent devenir poreuses, l’ouverture des services est un prérequis. Très logiquement, cette nouvelle édition est considérablement enrichie dans la dimen‑ sion API (interfaces), micro‑services et distribution sur le cloud. Une des marques de fabrique de ce livre est l’utilisation des patterns (« motifs de conception ») qui font le trait d’union entre la compréhension des problèmes – comme par exemple les problèmes de performance des architectures cloud – et la mise en œuvre des solu‑ tions – telles que le pattern CQRS du chapitre 8. Commençons par rappeler les enjeux qui justifient l’architecture orientée service. Le premier enjeu est « simplement » la réduction des coûts, en s’appuyant sur la réutilisation et la mutualisation. C’est l’enjeu le plus concret et le plus visible : il s’agit de construire un patrimoine de services partagés dans l’entreprise, réutilisés le plus souvent qu’il est possible. Le deuxième enjeu est lié, c’est celui de l’alignement stra‑ tégique du système d’information, qui est la clé de l’agilité au travers de l’anticipation. Le catalogue de services à produire doit être « prêt pour le futur », il représente le potentiel de situation du système d’information. Seule la co‑construction avec les directions métiers et utilisatrices permet de construire un catalogue « le mieux aligné possible » avec les enjeux présents et à venir de l’entreprise. Le troisième enjeu de SOA touche à la maîtrise de la complexité du système d’information. Autrement dit, comment répondre aux besoins d’aujourd’hui sans construire une « usine à gaz » tellement complexe qu’elle réduit considérablement les chances de pouvoir répondre demain aux nouveaux besoins. Il ne suffit pas de construire un catalogue de services pour faire du SOA, il faut construire des « services orientés‑architecture ». Autrement dit, il faut construire les bonnes pièces du lego, ce qui est difficile, et c’est précisément pourquoi le livre que vous tenez entre les mains est important. Pour que SOA fonctionne, il faut construire

📄 Page 14

PréfaceXVI des services abstraits, modulaires et recomposables. L’analyse fonctionnelle tradi‑ tionnelle que l’on pratique depuis 50 ans doit être intégrée au sein d’une modélisation des objets métiers et des processus métiers. La modularité, une propriété fonda‑ mentale du système d’information puisqu’elle gouverne l’agilité et la maîtrise des coûts (via la réduction des impacts), s’obtient au moyen d’une grammaire de services « bien découpés » (il s’agit plus d’un art fondé sur l’expérience que d’une science). La mutualisation et la réutilisation sont fortement liées à l’abstraction. Des services trop abstraits coûtent chers en adaptation et spécialisation, tandis qu’une abstraction trop faible réduit les possibilités de mutualiser. Pour reprendre une citation de ce livre, l’adoption de DevOps ne signifie pas qu’on puisse se passer d’architecture. Une fois le modèle des services esquissé, il reste encore à les implémenter, ce qui réserve quelques surprises. Pour en citer quelques‑unes, commençons par l’architec‑ ture de données. SOA ou non, les grands systèmes d’information reposent sur des architectures distribuées, qui posent des problèmes classiques de synchronisation et de cohérence. Ce livre aborde les questions importantes de distribution des objets métiers. SOA introduit une granularité et une distribution des services, ce qui pose des problèmes de performance (SOA n’est pas « scale-free », on ne peut pas décom‑ poser et distribuer n’importe comment les traitements sans souffrir de problèmes de performance). Les contrats de services et l’exploitation des services sont des sujets essentiels que ce livre aborde. Il donne également des conseils précieux pour bien utiliser les différents outils et les différents paradigmes techniques qui servent à l’implémentation de SOA. La dimension dynamique – voir le SI comme un processus continu de fabrication de services et non pas comme un catalogue – est essentielle aujourd’hui. Seule une organisation de « flux » permet d’atteindre l’agilité et de développer la capacité à profiter de la vague permanente de l’arrivée des nouvelles technologies et des oppor‑ tunités associées. Si le logiciel est un flux, le code redevient important, ainsi que la culture de « software craftsmanship ». Ce livre montre le code, avec modération, parce que SOA est en premier lieu une pratique. L’accélération de cette dynamique a conduit à proposer l’approche microservices, qui consiste à unifier le service exposé avec le système technique qui le délivre, pour obtenir une complète autonomie qui favorise modularité, agilité et scalabilité. On trouve également un chapitre sur la « SOA réactive », qui détaille les fondamentaux et la mise en œuvre d’une architec‑ ture dynamique organisée autour des événements (EDA : Event-Driven Architecture). Cette mise en correspondance permanente, dans cet ouvrage, des principes, de la pratique et de la mesure est essentielle car une SOA dynamique est construite à partir de l’usage, de façon adaptative. Une stratégie informatique moderne se décline forcément autour de ses inter‑ faces, internes et externes, avec le terme devenu incontournable d’API (Application Programming Interface). L’utilisation interne est tournée vers l’agilité et la réutilisa‑ tion, tandis que l’utilisation externe sert à exposer ses services au travers de parte‑ naires pour étendre sa distribution et à enrichir ses propres produits avec les services et compétences d’autres partenaires. Cette combinaison/ recombinaison doit se

📄 Page 15

Préface XVII produire partout, tout comme la mesure et l’analyse sont, au 21e siècle, des bonnes pratiques que l’on retrouve dans tous les composants du système d’information. Ce livre est un guide pratique qui aborde tous les sujets clés comme la sécurisa‑ tion, la gestion des versions ou la performance. Il traite à la fois la technique et la culture, puisqu’il rappelle au chapitre 22 qu’il faut « traiter les développeurs comme ses clients ». Ce livre me semble essentiel pour réussir sa transformation digitale. L’expérience enseigne qu’il y a trois conditions à respecter : 99 Adapter sa stratégie à ses moyens, son potentiel de situation, au lieu de continuer à penser d’abord et exécuter ensuite. 99 Savoir « cultiver » ce potentiel (depuis les compétences des équipes jusqu’à l’agi‑ lité du SI) de façon émergente, sans « tirer sur la tige de la plante pour la faire grandir plus vite ». 99 Pouvoir profiter de l’innovation externe et construire un SI ouvert qui permet à l’organisation de profiter de la richesse exponentielle des écosystèmes logiciels. Ce livre donne les clés de chacune de ces étapes. Premièrement l’approche SOA est précisément une approche de co‑construction de la stratégie et des moyens. Deuxièmement, ce livre insiste sur la mise en œuvre, les difficultés et la pratique car « c’est en forgeant qu’on devient forgeron » et c’est en utilisant les outils modernes et les piles logicielles ouvertes du cloud que l’on développe son potentiel d’agi‑ lité. Les compétences DevOps s’apprennent en pratiquant avec les bons outils. Troisièmement, ce livre donne les clés pour réussir conjointement à déployer une stratégie d’ouverture par les API et à ouvrir les capacités internes pour les interfacer avec les services externes. Je ne connais pas de recette simple pour réussir la transformation nécessaire des systèmes d’information pour permettre aux entreprises d’affronter un monde incer‑ tain, mais je suis persuadé que « SOA, microservices, API Management» est un des meilleurs outils disponibles pour réussir. Yves Caseau Group Chief Information Officer chez Michelin Membre de l’Académie des technologies, Président de la commission TIC.

📄 Page 16

(This page has no text content)

📄 Page 17

Le cahier des charges des SI agiles PREMIÈRE PARTIE L’objectif de cette première partie est d’introduire les problématiques de rationalisa‑ tion et d’agilité des systèmes d’information, puis de présenter un cahier des charges en regard des attentes et des défis actuels du SI. Ce dernier est envisagé sous un angle métier, puis sous un angle technique. Le premier chapitre présente l’évolution de l’informatique et les problématiques d’entropie des SI ; il montre que l’accélération globale du monde actuel risque d’ac‑ croître fortement ces problèmes si rien n’est fait. Une extension Web de ce chapitre montre que l’outillage (architectures, méthodes, techniques) mis à disposition des DSI jusqu’à présent ne résout que partiellement les problématiques de rationalisation du SI. Le deuxième chapitre présente les exigences métiers et techniques que l’on peut attendre d’une nouvelle démarche d’organisation et d’intégration du SI. Les parties suivantes montreront comment SOA répond à ces différentes exigences.

📄 Page 18

(This page has no text content)

📄 Page 19

Ce chapitre rappelle brièvement l’évolution des technologies informatiques et ses conséquences en terme d’entropie pour le système d’information. Il fait ainsi le constat de la difficulté à maintenir un SI homogène et rationnel. Il évoque ensuite les enjeux liés à la transformation digitale des SI et la pres- sion qui en découle pour ces derniers, et la nécessité d’évoluer vite, comme le font les géants du Web, afin d’éviter une disruption qui serait fatale à l’entreprise. Accepter l’entropie des systèmes d’information 1  1. 1   UNE BRÈVE HISTOIRE DE L’INFORMATIQUE 1.1.1  Les technologies mainframe et client/serveur Dans l’histoire de l’informatique, on a tout d’abord conçu des applications monoli‑ thiques, les sites centraux, où toute la logique de persistance, de traitement et de présentation était agrégée dans un ensemble indissociable. Toute l’informatique des entreprises était alors concentrée dans un serveur unique : le mainframe, qui consti‑ tuait le SI. Avec l’invention du PC sont apparues des applications plus légères en architecture client/serveur. Ces architectures ont proposé de déporter les composants d’interface sur les postes de travail en conservant des serveurs pour la persistance. Elles ont ainsi apporté plus de graphisme et plus de sophistication en termes d’ergonomie. Le faible coût de ces nouvelles applications a permis leur multiplication dans les entre‑ prises. Ces dernières se sont alors dotées de logiciels transverses de messagerie, de gestion fi nancière, d’aide à la décision, etc. De plus, l’informatique a commencé à être utilisée directement par les métiers et progressivement par tous les profi ls de l’entreprise.

📄 Page 20

4 Chapitre 1 Accepter l’entropie des systèmes d’information Ainsi, les systèmes d’information ont grandi rapidement à la suite d’initiatives éparses des différents départements et métiers de l’entreprise. L’absence de gouvernance de cette croissance a souvent abouti à des duplications d’informations, saisies et gérées de manière autonome par ces différents services. Le client/serveur a donc créé l’entropie des SI. 1.1.2  Les technologies Web À la fin des années 1990, les problématiques de déploiement et de gestion des parcs de PC ont montré les limites des applications client/serveur. Les technologies du Web sont, par essence, ouvertes, interopérables et aptes à fonc‑ tionner sur des réseaux distants. Les années 2000 ont vu leur adoption massive par les entreprises traditionnelles du tertiaire, d’abord pour connecter les clients de l’entreprise, puis les partenaires via les Web Services et l’émergence de SOA. En parallèle, les géants du Web, comme Google, Amazon ou Facebook, ont démontré dans ces mêmes années leurs capacités à gérer d’immenses volumes d’utilisateurs (1,7 milliard pour Facebook à fin 2016) et de données (des centaines de millions de vidéos vues chaque jour sur Youtube). Ainsi le Web est devenu une plate‑forme technologique de référence utilisée dans de nombreux SI. Elle a beaucoup évolué ces dernières années grâce à un riche écosystème de frameworks dans divers langages de programmation (Node.JS, Ruby On Rails, Groovy, Spring Boot...). Ces frameworks permettent un développement rapide grâce à des outils de packaging de composants (npm, bundle, bower...). Ils embarquent des outils de tests unitaires qui garantissent l’usage de bonnes pratiques de « développement piloté par les tests ». En 2014, HTML5 a transformé la plate‑forme Web en une véritable technologie d’in‑ terface client/serveur capable de fonctionner en mode déconnecté (web storage, local storage) et en mode asynchrone (web sockets), de créer des objets 2D et 3D (Canvas), etc. Ainsi, l’état de l’art est aujourd’hui la Single Page Application, une interface Web événementielle comparable à une application Visual Basic, donc assez éloigné du paradigme de navigation page à page. De fait, les technologies d’inter‑ face Web (GWT, Silverlight, Ember.JS, Angular, React, Ionic…) se sont succédé à un rythme rapide et même difficile à suivre par les entreprises. Le chapitre 10 clarifie les aspects architecturaux de ces technologies d’interface. Enfin, les géants du Web ont popularisé la mise à disposition de services comme Google Maps API, reposant sur le style d’architecture REST (partie 6). Ils ont ainsi créé des architectures distribuées avec une très forte capacité technique à monter en charge. 1.1.3  Le device agnostic La sortie de l’iPhone en 2007 puis de l’iPad en 2010 a donné le coup d’envoi des applications mobiles pour smartphones et tablettes. Les géants du Web ont alors commencé à proposer des interfaces device agnostic, c’est‑à‑dire utilisables sur tout