Architecture microservices
Les microservices sont une approche d’architecture et de développement d’une seule application composées de petits services. Ce qu’il faut bien comprendre dans les microservices, c’est leur indépendance. Chacun est développé, testé et déployé séparément des autres. Chaque service tourne dans un processus séparé. La seule relation entre les différents microservices est l’échange de données effectué à travers les différentes APIs qu’ils exposent. Ils sont une vue comme étant une amélioration des architectures SOA.
L’évolution de l’Internet des objets (IoT) et de la communication machine-à-machine (M2M) exige de structurer différemment les modules d’application. Chaque module doit s’occuper d’une seule tâche qui intervient dans le workflow global.
Pour chacune des parties d’une application, les développeurs choisissent les langages, les Frameworks et les outils les plus appropriés.
La technologie des conteneurs, surtout celle de Docker, permet de porter le code d’un environnement à l’autre. Les développeurs peuvent transférer en toute transparence le code écrit sur leurs machines de développement vers des machines virtuelles, ou vers le Cloud public ou privé. Chaque conteneur qui s’exécute est un ensemble complet, du système d’exploitation au code d’exécution de la tâche.
L’infrastructure sous forme de code est un concept puissant : il permet aux développeurs de gérer l’infrastructure sous-jacente via un programme. On peut ainsi provisionner, configurer et orchestrer de façon dynamique quelques centaines de serveurs virtuels. Combinée aux conteneurs, cette fonctionnalité offre de puissants outils comme Kubernetes pour le déploiement dynamique de clusters exécutant des microservices.
Pour chacune des parties d’une application, les développeurs choisissent les langages, les frameworks et les outils les plus appropriés. Ainsi, une grande application peut se composer de microservices écrits en Node.js, Ruby on Rails, Python, R et Java. Chaque microservice est écrit dans le langage le plus adapté à la tâche.
C’est également le cas de la couche de stockage permanent. Les applications Web ont toujours plus besoin de stockage objet, de stockage de données semi-structurées et structurées, et de cache en mémoire pour garantir la persistance. Les microservices facilitent l’adoption d’une stratégie polyglotte en termes de langages de codage et de bases de données.
Architecture Orienté Services
Les architectures orientées services (SOA) présentent un style d’architecture permettant d’assurer l’alignement métier et l’agilité dans le développement des applications. La SOA permet également la réorganisation du système d’information. Elle permet l’encapsulation des fonctionnalités d’un système d’information en un ensemble de services faiblement couplés appartenant à la fois au niveau métier et au niveau technique.
Objectif : L’objectif principal des architectures orientées services est d’assurer un alignement entre les activités métier et le système d’information d’une manière qui optimise l’efficacité et l’agilité de l’entreprise. En effet, dans une SOA, l’entreprise se base sur le modèle du domaine métier qui décrit le fonctionnement des activités pour concevoir des services réutilisables en tirant parti des propriétés des services. Ceci permettra d’adapter rapidement le système d’information suite aux changements métier. Dans les architectures orientées services, les nouvelles activités métier pourront être perçues comme étant des processus métier réalisés par des services. En effet, l’objectif principal dans une SOA est de découper les activités métier en des séries d’activités réutilisables qui pourront être complètement ou partiellement automatisées par des services métier. Les services reflètent à la fois l’image métier des activités et l’image technique des fonctions implémentées au niveau du système d’information.
La gouvernance SOA
Afin d’expliciter ce concept, nous commençons par rappeler les concepts liés à la gouvernance de l’entreprise et des systèmes d’informations. La gouvernance de l’entreprise définit les règles et la manière dont l’entreprise mène ses activités en se basant sur la stratégie métier et le marché. La gouvernance des systèmes d’information définit le processus et les règles permettant de diriger, contrôler et optimiser la gestion du système d’information pour atteindre les objectifs métier de l’entreprise.
Directement décliné de ces principes, la gouvernance SOA permet de s’assurer que les concepts et les principes de l’architecture orientée services est gérée de façon appropriée et que les objectifs métier sont respectés.
Dans un environnement SOA, les responsables métier et techniques devront assurer la qualité des services en prenant en compte la totalité des phases du cycle de vie de ces services. À titre d’exemple, les responsables métier devront veiller à la bonne application des contrats de qualité de service. Les responsables techniques devront veiller à la mise en place, la maintenance et la supervision des services.
Après le déploiement d’un service, le suivi doit être organisé pour contrôler et superviser l’architecture. La gouvernance SOA définit les politiques et les processus nécessaires pour contrôler le développement, le déploiement et la gestion des services en intégrant entre autres la sécurité. Ces politiques et processus de gouvernance sont d’une importance cruciale dans la définition du contexte de la SOA à sécuriser et pour permettre la gestion de la sécurité. Toutefois, la performance globale est largement dépendante des phases de conception et de déploiement de l’architecture.
Mise en œuvre d’une SOA : Les services web
L’instance la plus connue des architectures orientées services est basée sur les services web bien que d’autres technologies (CORBA ou Enterprise Java Beans) permettent aussi cette mise en œuvre.
Le Web a rencontré un grand succès en permettant des interactions simples entre l’utilisateur et l’ordinateur au niveau d’Internet. Le principal facteur du succès de HTTP et de HTML réside dans leur relative simplicité.
Un service Web peut être vu comme étant une application accessible par une interface spécifiée selon le standard Web Services Description Langage WSDL. De plus, l’interaction entre les services web se fait via le standard SOAP. Ainsi, les services web utilisent des standards pour décrire leur fonctionnement et la façon d’interagir avec eux. Le fournisseur de service ; Le demandeur de service.
Un troisième acteur peut éventuellement venir s’ajouter à ce couple, l’annuaire de service permettant de répertorier l’ensemble des fournisseurs de services. Les services Web s’appuient sur un ensemble de protocoles standards. La communication s’effectue grâce aux protocoles standards d’Internet : HTTP, HTTPS…Les services Web se fondent sur XML1 qui est un langage de bannières permettant d’écrire des contenus organisés de manière hiérarchique. Le principal intérêt d’XML est que ce format de document permet de transmettre l’information, mais aussi les métadonnées qui indiquent sa signification, et la structure de l’information à échanger. La totalité des acteurs de l’industrie des services Web adhèrent au socle technique des services Web : les protocoles UDDI, WSDL et SOAP. Ces normes régissent l’interopérabilité des services Web et permettent de faire inter opérer des systèmes d’information hétérogènes :
UDDI2 définit les formats pour crées des catalogues pour publier et rechercher des services Web. WSDL3 permet de spécifier le format des messages, les protocoles qui doivent être utilisés et la localisation des différentes machines qui mettent en œuvre un service Web. SOAP4 permet la normalisation des échanges de données.
Les stratégies dans le développement de systèmes sécurisés
Sécuriser un système revient à prendre en compte la sécurité dès les premières phases de la conception. Le développement de systèmes sécurisés, qu’il s’agisse de systèmes d’informations, d’architectures à base de services ou d’applications monolithiques, peut être effectué en utilisant des méthodologies d’analyse des risques, des modèles de conception et des patrons de sécurité. Dans ce qui suit, nous présentons le concept des patrons de sécurité.
De manière générale, un patron constitue une base de savoir et de savoir-faire pour résoudre un problème récurrent dans un domaine particulier. La spécification de ces connaissances réutilisables: Permet d’identifier le problème à résoudre par capitalisation et organisation de connaissances d’expériences ; Propose une solution possible, correcte, générale et consensuelle pour y répondre; Offre les moyens d’adapter cette solution au contexte spécifique.
A partir des spécifications d’un problème récurrent, les patrons permettent d’obtenir les informations et connaissances organisationnelles pour y faire face. Les patrons de sécurité aident les architectes et les développeurs à partager des connaissances sur la sécurité, à définir un nouveau paradigme de conception ou un style d’architecture, à identifier les risques qui ont été traditionnellement identifiés par prototypage ou par expérience intégrant les visions métier et technologiques de la sécurité.
Table des matières
1.PRESENTATION GENERALE
RESUME
1.1 PRESENTATION DU MASTER
1.2 CONTEXTE DU PROJET
1.3 PROBLEMATIQUE
1.4 OBJECTIFS A ATTEINDRE
CONCLUSION
2.PRESENTATION ET ETUDE COMPARATIVE
RESUME
2.1 PRESENTATION
2.2 ARCHITECTURE MONOLITHIQUE
2.2.1 Limite et faiblesse
2.3 ARCHITECTURE ORIENTE SERVICE
2.4 ARCHITECTURE MICROSERVICES
2.5 DIFFERENCE ENTRE LES SOA ET LES ARCHITECTURES MICROSERVICES
CONCLUSION
3.SOA ET MICROSERVICES
RESUME
3.1 LES SERVICES
3.2 ARCHITECTURE ORIENTE SERVICES
3.2.1 Définition
3.2.2 Objectif
3.2.3 La gouvernance SOA
3.2.4 Méthodologies de développement des architectures orientées services
3.3 MISE EN ŒUVRE D’UNE SOA : LES SERVICES WEB
3.3.1 Architecture Services web
3.3.2 Architecture Rest
3.4 ARCHITECTURE MICROSERVICES
3.4.1 Une Amélioration de l’architecture orientée services
3.4.2 Caractéristiques de l’architecture micro services
3.4.3 Bilan sur l’architecture micro services
3.4.4 Mise en Œuvre d’une architecture Micro services
CONCLUSION
4.SECURITE DE SOA ET MICROSERVICES
RESUME
4.1 CONCEPTS LIES A LA SECURITE
4.1.1 Les objectifs de sécurité
4.1.2 Les objectifs de base de sécurité
4.1.3 Les Objectifs de support de sécurité
4.1.4 Les mesures de sécurité
4.1.5 Types de menaces de sécurité des web services et solutions
4.1.6 Les stratégies dans le développement de systèmes sécurisés
4.1.7 Approches de sécurité des SOA
4.2 SECURITES DES MICROSERVICES
4.2.1 Pratique pour sécuriser les micro services
4.2.2 Bénéfices de la sécurité des micro services
4.2.3 OAuth en tant que protocole de délégation
CONCLUSION
5.MISE EN ŒUVRE
RESUME
5.1 CHOIX DE LA TECHNOLOGIE
5.2 JHIPSTER
5.2.1 Pile technologique
5.2.2 Prêt à entrer en production
5.3 CONSTRUCTION D’UNE ARCHITECTURE MICROSERVICES AVEC JHIPSTER
5.3.1 Installation de JHipster
5.3.2 Architecture micro services
5.3.3 Création d’une passerelle API
5.3.4 Création d’un micro service
5.3.5 Déployer vers le Cloud
