Architecture

Déporter des traitements lourds, transférer des logs, gérer des pics de charges, architecture réactive… Il existe de nombreux cas d’utilisation du design pattern Asynchronous data exchanges qui permet de gérer la communication de message en mode asynchrone. De nos jours, plein de solutions existent pour l’implémenter : Utilisation de méthode intégrée aux langages : Futures en Java Actors et Futures en Scala Delegate en .Net Utilisation d’outil comme Netty Utilisation de serveur de message ou MOM (Message Oriented Middleware) Etc. Dans cette série d’articles, nous…

Nous voilà à la fin de cette série d'articles (disponibles ici, ici et ici) sur le circuit breaker. Comment fais je pour le superviser en production ? Notre application a passé tous les tests et il est temps de passer en production. Si l’on reste sur Hystrix, il existe beaucoup de métriques. La liste est disponible sur le site officiel. Une des difficultés d’une bonne supervision est de réussir à obtenir des tableaux de bord où avec un simple coup d’oeil on peut obtenir le…

Maintenant que nous avons vu la théorie sur les précédents articles disponibles ici et ici, penchons-nous sur la pratique. Comment l’implémenter ? Plusieurs solutions sont possibles pour l’implémenter. Par exemple en Java il existe des librairies qui le font pour nous comme : Spring Cloud Netflix Netflix Hystrix breakr Focalisons-nous sur Netflix Hystrix.

Lors de l'article précédant, nous avons vu quelques solutions possible pour résoudre la gestion des dépendances (externe ou interne) qui peuvent (et le seront tôt ou tard) défaillantes lors de l’exécution de notre application. Regardons d'un peu plus près le design pattern circuit breaker. Une solution possible : le design pattern circuit breaker ? Le circuit breaker permet de contrôler la collaboration entre différents services afin d’offrir une grande tolérance à la latence et à l'échec. Pour cela, en fonction d’un certain nombre de critères d’erreur (timeout,…

L'évolution des besoins (réductions des coûts et du time to market, concept d'ATAWAD (AnyTime, AnyWhere, AnyDevice)...) a mis en avant certaines architectures (architecture  applicative cloud ready, architecture microservices, architecture distribuée…). Cela a engendré de nouvelles problématiques, en particulier l’augmentation du nombre de dépendances et donc potentiellement soumise au réseau. C’est à ce moment qu'apparaissent à nouveau les “Illusions de l'informatique distribuée” : Le réseau est fiable. Le temps de latence est nul. La bande passante est infinie. Le réseau est sûr. La topologie du réseau…

Jeudi 21 Janvier, l’équipe en charge des technologies Réactives d’OCTO Technology a présenté sa vision des nouvelles architectures Réactives (Vidéo ici, slide là).  

En 2015, le pic des microservices a été atteint : pas une conférence sans un ingénieur de Netflix pour vous vendre du rêve, pas une semaine sans nouveau framework magique pour tout faire sans se poser de question. Résultat : une focalisation sur les outils et les belles histoires plutôt que sur les questions de fond. Il nous a donc semblé utile de faire le point sur les aspects architecturaux des microservices, car choisir un style d’architecture pour un système d’information a des conséquences structurantes…

Avec l’arrivée de REST, on est tenté d’oublier tout ce qu’on faisait avant car c’était forcément moins bien. Mais, si les technologies ont changé, les bonnes pratiques SOA sont toujours aussi pertinentes, et permettent de mettre en œuvre des services qui répondent aux besoins tout en gardant la maîtrise de son système d’information.

Après avoir décrit le monitoring de flux et les bonnes pratiques pour le mettre en place, passons à un cas pratique. Nous allons détailler un exemple complet et documenté de monitoring d’un mini-système d’information combinant appels de services et envois de messages, avec des modèles de code.