Aujourd’hui, on va parler d’équilibrage de charge (aka. load-balancing) et plus particulièrement des solutions proposées par Microsoft sur son cloud Azure.
Avant de rentrer dans le vif du sujet, prenons un peu de temps pour définir ce qu’est l’équilibrage de charge et à quoi ça sert.
L’équilibrage de charge désigne le fait de distribuer des charges de travail sur plusieurs ressources. Il vise plusieurs objectifs :
optimisation de l’utilisation des ressources optimisation du débit réduction du temps de réponse éviter la surcharge d’une seule ressource amélioration de la disponibilité / redondance Source : https://learn.
Entity Framework Core 7 est déjà sorti il y a quelque temps maintenant (le 8 Novembre 2022 si vous n’avez pas cliqué sur le lien…), mais je souhaitais revenir sur l’arrivée de la stratégie TPC (Table Per Concrete), et au passage, en profiter pour présenter les différentes possibilités pour gérer l’héritage avec EF.
Entity Framework Core Entity Framework Core est un ORM (aka. object-relational mapping) dédié au monde .NET. Il succède à Entity Framework, et vient lui apporter légèreté et extensibilité ainsi que le support du multiplateforme et la diffusion du code en open source.
J’ai récemment eu besoin de mettre en place un mécanisme permettant l’ajout automatique de tags sur des ressources Azure. Il s’agissait de positionner des tags pour tracer les modifications sur des ressources (auteur et date de création/modification). J’en profite donc pour faire un feedback technique, et aborder au passage la brique Azure Event Grid.
Comment ça fonctionne ? Le fonctionnement est globalement assez simple, et ne nécessite que 2 composants :
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.
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.
Vaste sujet ! Dans cet article, nous allons parler clean code, dette technique, refactoring et anti-patterns. Il fait suite à la série sur les designs patterns que vous pouvez retrouver ici :
Les design patterns et les principes SOLID en développement logiciel Les patterns creationals Les patterns structurals Les patterns behaviorals Tout logiciel est constitué de code, et c’est la qualité de ce code qui va faire d’une application une application de qualité.
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.
C’est la capacité d’une application à s’adapter à la charge, c’est-à-dire le nombre d’utilisateurs pouvant être servis simultanément.
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.
Suite à l’article d’introduction, les premiers types de patterns que je vais aborder sont les creational patterns ou patrons de création. Il en existe 5 et ils permettent de définir la manière de faire l’instanciation et la configuration des classes ou des objets de manière souple tout en minimisant le couplage et en maximisant la réutilisation du code.
Table des matières Singleton Factory Abstract Factory Builder Are you fluent ? Prototype Singleton C’est probablement le design pattern le plus connu et le plus utilisé.