Contraintes de performances d’une application monolithique
Il existe de nombreuses raisons pour lesquelles vous pouvez choisir de modifier l’architecture d’un système. L’agilité opérationnelle, le coût, la scalabilité et les performances ne sont que quelques facteurs qui jouent un rôle dans la détermination de l’architecture d’un système. Dans notre exemple, nous examinons de plus près comment les performances deviennent un facteur déterminant pour le système de livraison par drone.
À mesure que l’activité de livraison par drone de Fabrikam s’accroît, la charge du système augmente. L’architecture actuelle est en surcharge. Fabrikam souhaite offrir une meilleure flexibilité pour la mise à l’échelle de l’application, qui n’est pas disponible dans l’architecture monolithique actuelle. L’amélioration de la scalabilité de l’application est l’un des facteurs qui poussent Fabrikam à envisager le transfert de son application vers une architecture de microservices.
Mise à l’échelle d’un monolithe et de microservices
L’un des principaux avantages d’une architecture de microservices est l’augmentation des capacités de mise à l’échelle. Les services étant séparés, il est plus facile de mettre à l’échelle chaque service individuellement à mesure que la charge qui s’y applique augmente.
Nous pouvons voir cette différence de fonctionnalités dans le système de livraison par drone. Avec une architecture monolithique, tous les services sont inclus dans une seule instance de l’application. Ils exposent une interface d’API aux clients pour soumettre et gérer des demandes de livraison. À mesure que les demandes des clients augmentent, la charge sur le système grandit. Il est nécessaire d’allouer plus de ressources au système pour éviter d’affecter négativement l’expérience de l’utilisateur.
Dans une architecture monolithique, la mise à l’échelle individuelle de ce service nécessite également la mise à l’échelle des ressources des autres services, car ils sont inclus dans chaque instance d’application. Cette organisation est inefficace, car la charge pour les autres services peut être minime et ne pas nécessiter l’utilisation de ressources supplémentaires.
Dans une architecture de microservices, comme chaque service est séparé, il est possible de mettre à l’échelle l’API indépendamment des autres services. Cette organisation augmente l’efficacité, car nous n’avons pas besoin de consommer les ressources de services inutiles.
Défis liés à l’architecture monolithique de Drone Delivery
Le service de traitement des colis a été identifié comme une partie essentielle de l’activité et faisait partie à l’origine de l’architecture monolithique. Les clients ont considérablement augmenté leur dépendance vis-à-vis de ce service, et les performances sont affectées à mesure que cette charge augmente. Pour remédier à cette situation, Fabrikam a mis en place une équipe de développement dédiée disposant d’un contrôle total sur cette partie de l’activité. L’équipe, qui prévoit de développer et d’effectuer des itérations sur ce service, est seule responsable de tous les aspects du service de traitement des colis.
Étant donné que le service de package se trouve dans le monolithe, l’équipe ne peut pas fonctionner de manière autonome. Ils doivent s’appuyer sur des données et des structures de données partagées. Ils ne peuvent pas effectuer d’itération aussi rapidement qu’ils le voudraient. Outre les problèmes de performances et de scalabilité, ce service est identifié comme un candidat de choix pour un microservice.
Examinons de plus près comment Fabrikam peut analyser et décomposer son application pour tirer parti d’une architecture de microservices.