L’architecture de microservices devient de plus en plus populaire parmi les développeurs d’applications, grâce à sa flexibilité et son évolutivité qui permettent d’ajouter des mises à jour et de nouvelles fonctionnalités sans remanier l’ensemble du système. Cependant, l’utilisation d’interfaces utilisateur, de bases de données et de serveurs distincts pour chaque microservice rend l’optimisation des applications un défi, compte tenu de la diversité des langages de programmation et des problèmes de sécurité des API.
L’équipe Freshcode a eu du mal à mettre à jour une ancienne application EdTech fonctionnant sur MS SQL qui utilisait plus de 10 000 fichiers créés dans ColdFusion et comportait des dizaines de microservices pour des fonctionnalités disparates. L’application était destinée aux gouvernements et aux réseaux éducatifs avec des centaines de campus et d’écoles et disposait d’un ensemble complet de fonctionnalités pour apaiser à la fois les universités nationales et les petites écoles. Avec des opérations de microservice conflictuelles, la création de rapports était un problème auquel l’équipe FreshCode devait s’attaquer.
Comment améliorer les performances des microservices
L’engagement de différents microservices a causé une pléthore de problèmes de performances pour l’application EdTech, nous avons donc eu l’idée de développer un nouveau microservice de reporting. Au lieu d’essayer de concilier des technologies conflictuelles, le nouveau microservice obtiendrait des données directement à partir de différentes bases de données, les transmettrait via les systèmes de messagerie et de calcul à la vapeur avant de les stocker dans une base de données distincte. Après cela, le microservice pourrait utiliser les données de la base de données pour créer des rapports personnalisés.
La tâche a été encore compliquée par la nécessité de développer deux solutions identiques (versions auto-hébergées et SaaS). L’équipe a donc parcouru plusieurs alternatives technologiques pour chaque aspect du microservice de reporting afin de proposer la meilleure pile pour les deux schémas de déploiement.
Implémentation du module de reporting en 6 étapes
L’équipe Freshcode a divisé le processus de développement de microservices en six étapes. Et comme toujours, ils ont commencé par analyser les besoins et sélectionner les meilleures technologies et solutions.
1. Modification de la capture de données
Oracle était la base de données centrale des microservices de reporting, nous avons donc opté pour StreamSets Data Collector en tant que solution open source personnalisable avec prise en charge intégrée d’Oracle CDC. Matillion et Apache NiFi sont également conviviaux et appréciés des développeurs, et ils auraient fait la coupe s’ils avaient offert un support Oracle similaire.
2. Système de messagerie
L’équipe de développement a choisi Apache Kafka comme système de messagerie durable, évolutif et tolérant aux pannes. Bien qu’elle nécessite des DevOps experts, la solution propose des calculs in-stream natifs et un mode batch. De plus, contrairement à AWS Kinesis, Apache Kafka peut être utilisé en interne.
3. Systèmes de calcul en continu
Malgré son architecture compliquée, Apache Flink était le meilleur choix pour l’application EdTech grâce à sa tolérance aux pannes, son évolutivité, sa faible latence et sa cohérence d’état exactement une fois. Les services AWS Kinesis figuraient également parmi les meilleurs choix, mais ils ne pouvaient pas être utilisés sur site. Freshcode a donc dû renoncer à la solution AWS.
4. Lac de données
AWS S3 a été choisi pour créer un dépôt de données historiques et actuelles. Il s’agit d’une solution open source durable et économique, facile à intégrer à d’autres produits AWS. L’équipe Freshcode a considéré Apache Hadoop comme une alternative valable, bien qu’il s’agisse d’une option plus difficile en matière de déploiement et de gestion.
5. Bases de données de rapports
Le microservice de génération de rapports devait fonctionner avec d’autres modules d’application, et l’équipe a suggéré AWS Aurora comme le meilleur choix. C’est assez rapide pour une base de données SQL tout en étant hautement évolutif et durable. Bien que l’instance minimalement disponible soit trop grande, elle pourrait être remplacée par PostgreSQL simple. Les autres options envisagées par l’équipe comprenaient AWS Redshirt, Apache Druid et Kinetica.
6. Signaler un microservice
Les principales fonctionnalités du microservice comprenaient le stockage des objets de données et de leurs relations, ainsi que la génération de rapports personnalisés basés sur les objets de données sélectionnés.
Piles technologiques pour les solutions SAAS et auto-hébergées
Les développeurs Freshcode ont choisi NodeJS pour créer un microservice pour la solution SaaS EdTech. Il s’appuyait principalement sur des produits AWS, comme AWS S3, Aurora et ElasticCache, complétés par StreamSets et Apache Kafka. Cette pile technologique était idéale, car elle pouvait être facilement remplacée par des alternatives auto-hébergées sans perturber le code et la logique du microservice pour un autre schéma de déploiement.
Le microservice de reporting interne a utilisé Minio, PostgreSQL et Redis à la place, car leurs API sont entièrement compatibles et offrent un fonctionnement transparent.
Conclusion : rapports personnalisés dans les microservices
La mise en œuvre réussie du microservice de reporting, ainsi que d’autres améliorations réalisées par Freshcode, ont permis à la société EdTech de mettre à jour la conception et l’architecture de l’application et de l’améliorer grâce à l’ajout de fonctionnalités nouvelles et améliorées. En outre, en supprimant les problèmes de performances de reporting, l’application est devenue plus flexible et évolutive pour le déploiement en interne et SaaS.
Si vous souhaitez en savoir plus sur les spécificités de ce projet et les détails du développement de microservices de reporting avec des estimations de calendrier et de budget, consultez l’étude de cas complète d’EdTech.