Apache Pulsar est une plateforme de messagerie distribuée et de streaming de données. Initialement développé par Yahoo en 2015, Pulsar est depuis 2017 sous la responsabilité de la fondation Apache. La création de Pulsar a été motivé par la nécessité de disposer d’une solution qui pourrait surmonter les limitations des systèmes existants, notamment la scalabilité horizontale, le multi-tenant et la flexibilité.

Continuer

À l’ère du numérique, où chaque seconde génère d’innombrables données, la capacité à traiter, analyser et agir sur ces informations en temps réel est devenue un avantage concurrentiel majeur pour les entreprises. Les plateformes de streaming de données émergent comme la réponse à ce besoin pressan. Explorons ensemble les concepts clés du streaming de données, tout en plongeant dans quelque unes des solutions les plus populaires du marché.

Continuer

L’observabilité, c’est l’outil qui permet d’affirmer qu’un système est actif ou non et, lorsqu’il est actif, de déterminer s’il fonctionne correctement ou fait preuve d’une défaillance.

Continuer

Construire une infrastructure a toujours été un processus manuel long et coûteux (et ce, même via l’utilisation de script “maison”). Avec l’avènement du cloud et l’accélération de la mise en production des applications, il est devenu indispensable de mettre en place des méthodes pour gérer cela de manière efficace, fiable et performante. Pour faire du déploiement un “non-évènement” et supprimer la peur du “friday deployment”, on est venu ajouter de l’outillage et de la méthode sur tout ça.

Continuer

Dans mon article sur la scalabilité et la haute disponibilité, j’avais rapidement abordé le sujet du pattern CQRS. Aujourd’hui, nous allons voir un peu plus en détail les concepts et le fonctionnement de ce pattern. CQRS, qu’est-ce que c’est ? CQRS, pour Command Query Responsibility Segregation, est un pattern reposant sur le principe de la séparation des opérations de lecture (Query) et d’écriture (Command) Ce pattern est né du constat que les besoins, fonctionnels ou techniques, d’une application sont souvent très différents selon que l’on cherche à lire ou à modifier une donnée.

Continuer

Dans mon précédent article sur la scalabilité et la haute disponibilité, j’avais abordé le concept d’architecture microservices. Je vais aujourd’hui détailler un peu plus ce type d’architecture qui répond à de nombreuses problématiques rencontrées par les entreprises. Dans son article Who Needs an Architect?, Martin Fowler développe sa propre définition de l’architecture : À première vue, l’architecture d’une application se résume en la décomposition de la totalité du système applicatif considéré en éléments constitutifs plus simples, aux rôles, responsabilités et limites bien identifiés.

Continuer

Troisième et dernière catégorie de pattern que je vais aborder, les behavioral patterns ou patrons de comportement. Il en existe 11 et ils permettent de définir comment organiser nos objets pour que ceux-ci collaborent. Si jamais vous les avez ratés, je vous invite à (re)lire les parties précédentes : L’introduction sur les design patterns Les patterns creationals Les patterns structurals Table des matières Chain of responsibility Pipeline Command Interpreter Iterator Mediator Memento Observer State Strategy Template Visitor Chain of responsibility Ce pattern permet de séparer les objets émetteurs de requêtes et les objets chargés de recevoir et traiter les requêtes.

Continuer

Après les patterns creationals (que vous pouvez retrouver ici), je vais maintenant aborder les structural patterns ou patrons de structure. Il en existe 7 et ils permettent de définir comment organiser nos objets. Si vous le souhaitez, vous pouvez retrouver l’introduction sur les design patterns ici. Table des matières Adapter Bridge Composite Decorator Façade Flyweight Proxy Adapter L’objectif du pattern Adapter est de faire passer quelque chose pour autre chose sans perturber le reste de l’application.

Continuer