Article #1 – Contexte et définition de l’application

Pour commencer cette série d’articles sur le sujet des microservices, il convient d’établir le contexte autour de ce type de projet. S’en suivra une tentative de définition du terme microservice, avant d’ouvrir sur l’application qui servira de preuve du bon fonctionnement de l’écosystème.

Rappel : Cet article s’inscrit dans une série d’articles formant un retour d’expérience sur la création d’une architecture orientée microservices.

• Article #1 – Contexte et définition de l’application
• Article #2 – Eureka, registre de services au coeur de l’architecture
• Article #3 – Zuul, gatekeeper et filter loader depuis Cassandra
• Article #4 – Hystrix, son dashboard et la stack ELK
• Article #5 – Quelques éléments de conclusion

Introduction

Ce REX a été mis en place afin de décrire la procédure de création d’une architecture orientée microservices de toutes pièces. Il décrit les conclusions d’une étude technique réalisée chez Ippon, sous la tutelle de David Martin, directeur du pôle conseil et formation et travaillant chez Ippon Nantes, qui a, par ailleurs, écrit un article au sujet de l’avènement des microservices.

Définition d’un microservice

Le terme microservice jouit d’une popularité de plus en plus importante depuis le début des années 2010. Plusieurs définitions ont été établies depuis le temps, mais la plupart des experts en informatique s’accordent sur une même idée pour pouvoir décrire ce style d’architecture. Il s’agit d’une approche pour développer une application composée de plusieurs petits services, ayant chacun leur processus et utilisant des mécanismes de communication légers. Chacun de ces services doit pouvoir exécuter une partie unique et spécifique de l’application, et être déployés indépendamment des autres services. Il est important de noter que ces services peuvent être écrits dans des langages informatiques différents, et utiliser des systèmes de persistance qui le sont tout autant.

Adrian Cockroft, personnage influent dans le monde du Cloud, a donné une définition concise de ce qu’est une architecture microservice, très répandue dans le domaine :

“Loosely coupled service oriented architecture with bounded contexts”

Ce qui signifie en français : Architecture orientée services à couplage faible dans un contexte confiné. Le couplage faible représente le peu de liens physiques entre les services. En ce qui concerne le contexte, il s’agit ici de démontrer qu’il y a bien isolation entre les différents métiers de l’architecture.

Certaines personnes iront même jusqu’à assimiler les microservices aux architectures de type SOA, à travers de nombreuses similarités entre les deux modèles, notamment le principe d’autonomie des services. Vous pourrez vous référer à cet articlede Martin Fowler pour plus d’informations sur le concept des microservices.

De la théorie à la pratique

Alors que les discussions autour du potentiel d’un tel modèle ont continué de nourrir Internet, plusieurs personnes s’y sont intéressé de plus près, soit pour décrire le modèle, comme l’a fait Martin Fowler dans son article “Microservices”, soit pour le mettre en oeuvre dans un contexte réel. Adrian Cockcroft, architecte Cloud chez Netflix, a entrepris, en 2010, la mise en place d’une telle architecture au sein de l’entreprise. Devant un tel challenge, il décide donc de se pencher sur le tout nouveau modèle microservice pour étudier la viabilité de la méthode. Au terme de la mise en place de l’architecture chez Netflix, il déclarera que ce style d’architecture microservices s’assimile à du SOA plus précis.

@kellabyte @mamund I used to call what we did “fine grain SOA”. So microservices is SOA with emphasis on small ephemeral components

— adrian cockcroft (@adrianco) 11 Décembre 2014

Il fut l’un des premiers à utiliser le modèle microservice et à appliquer ce paradigme au sein de Netflix. De cette opération ambitieuse est né un mouvement de partage de logiciels OpenSource très important de la part de la firme américaine, donnant naissance à Netflix OSS. C’est sur cette base de logiciels que notre architecture a été construite. Mais pas seulement…

Spring a aussi profité de cette nouvelle tendance pour enrichir son catalogue de services, avec la création du projet Spring Cloud, ayant pour vocation de rassembler les outils principaux à la création d’applications orientées systèmes distribués. Plusieurs modules composent ce nouveau projet, notamment Spring Cloud Netflix.

Et c’est donc la combinaison de ces deux projets Spring Cloud et Spring Cloud Netflix, et de la stack Netflix, qui va permettre de créer notre écosystème. Nous y ajouterons un système de persistence basé sur Apache Cassandra, ainsi qu’un système de logging avec la stack ELK.

Partie 1 – L’application en tant que preuve

Afin de mieux assimiler le processus de création de l’architecture, plusieurs parties seront créées pour ce REX, et seront réparties sur la totalité des articles.

Pour bien comprendre le fonctionnement de l’architecture, il a été décidé de créer une application toute simple, permettant de démontrer le bon déroulement des opérations et l’intéret de l’architecture.

Notre application sera à l’image d’une page produit Amazon (entreprise ayant aussi adopté une architecture microservices). Pour cela, 3 services seront créés :

• Product : représentant le produit en l’état
• Details : fournissant des informations sur les détails du produit
• Pricing : fournissant des informations sur les prix pratiqués pour la vente de ce produit

Voici une représentation graphique des interactions entre ces 3 services :

Product devient donc le point d’entrée de l’application, et en fonction de certains paramètres de la requête, il sera en mesure de savoir s’il faut requêter Details ou Pricing, ou les deux. Le but premier étant de faire communiquer 3 entités différentes entre elles, nous ne parlerons pas, pour l’instant, de système de stockage de données.

La mise en place de ces services est donc facilitée par le créateur de projets REST Spring Boot. Cela va nous permettre de nous abstraire d’une certaine quantité de code étant donné que nous ne voulons qu’un service qui puisse recevoir une requête et soit la transmettre à un autre service, soit constituer la réponse et la renvoyer, pour l’instant.

NB : L’application est volontairement légère car elle ne constitue pas la partie la plus importante de l’architecture. Le but est uniquement d’avoir une certaine quantité de services que l’on puisse utiliser et qui serviront à prouver le bon fonctionnement d’une architecture microservice.

Voici un exemple de service côté main et controller :

@EnableAutoConfiguration
@SpringBootApplication
public class DetailsApplication {

    public static void main(String[] args) {
    	SpringApplication.run(DetailsApplication.class, args);
    }
}

DetailsApplication.java

@RestController
@RequestMapping("/details")
public class DetailsController {

	@RequestMapping(value = "/{id}", method = RequestMethod.GET)
    public DetailsDTO find(@PathVariable String id) {
		/* do something here */
    }
}

DetailsController.java

Chacun de ces services est donc reconnu par une adresse IP unique. Voici les IP attribuées ici, à titre d’exemple :

• Product : http://127.0.0.1:8080/products/
• Details : http://127.0.0.1:8181/details/
• Pricing : http://127.0.0.1:8282/pricing/

Afin que Product puisse récupérer les informations depuis Details et Pricing, il faut lui fournir les adresses IP de ces derniers, ce qui rend le couplage très fort entre les services. En vertu d’une architecture microservice, il faut que les services puissent communiquer indépendamment les uns des autres, sans qu’ils aient besoin de se connaître.

C’est ici qu’intervient Eureka, le registre de services développé par Netflix, que nous utiliserons conjointement avec Spring Cloud dans le second billet de ce REX !