eXp Realty adopte une architecture de microservices d'entreprise
Quand est-il judicieux de passer à une architecture de microservices ? Il s'agit d'une question urgente que se posent de nombreuses organisations lorsqu'elles évaluent leur architecture technologique logicielle existante dans le but de devenir plus agiles.
En tant qu'industrie, l'immobilier est local. Chaque État fait le même type d'activité, mais de manière différente. eXp Immobilier, le sixième plus grand courtier immobilier aux États-Unis et la première société immobilière basée sur le cloud au monde, cela impliquait de mettre à jour son application commerciale essentielle à la mission, eXp Enterprise.
Les agents, sous-traitants et employés d'eXp utilisent eXp Enterprise, une application basée sur le cloud développé sur le Mendix plateforme, pour mener des activités commerciales essentielles telles que l'intégration et l'enregistrement des transactions. eXp a initialement construit l'application sur une architecture monolithique.
Pour rester compétitif, Steve Ledwith, vice-président de l'ingénierie chez eXp Realty, a identifié la nécessité de réarchitecturer l'application d'une architecture monolithique vers des microservices. Cette réarchitecture a représenté une entreprise de grande envergure pour l'entreprise, sachant qu'eXp exerce ses activités dans les 50 États américains. Mais en établissant une vision, en obtenant l'adhésion de toutes les parties prenantes et en permettant à ses développeurs de faire évoluer cette application essentielle à l'entreprise vers des microservices.
La nécessité d’un changement au niveau de l’entreprise
Au fil des années, eXp a fait passer son activité de 2,500 18,000 agents à XNUMX XNUMX. Par conséquent, les fonctionnalités, la base d'utilisateurs et les exigences d'hébergement d'eXp Enterprise ont également augmenté, ce qui a entraîné une forte demande. dette technique que Ledwith devait résoudre.
La bonne façon ou maintenant ?
Au moment de son lancement, eXp Enterprise proposait 30 fonctionnalités. En moins de deux ans, eXp a ajouté 1,700 2,000 fonctionnalités à l’application, avec XNUMX XNUMX utilisateurs qui l’utilisaient quotidiennement. La gestion de ces fonctionnalités avec une base d’utilisateurs de cette taille a nécessité ce que Ledwith a appelé des approches « immédiates » ou des développements ad hoc de l’application afin de répondre aux besoins commerciaux immédiats. Ledwith résume parfaitement ce problème en disant :
« Donc, au lieu de faire les choses correctement, nous les avons faites tout de suite et il y a eu un manque flagrant de participation », explique Ledwith.
Pour un modèle de domaine de base de données, le Mendix-way prescrit un modèle propre – une ou deux entités et modules. Mais le modèle de domaine de base de données d'agents d'eXp qui contient des informations sur les agents était étroitement couplé.
Regardons quelques chiffres :
- Dans une zone de la base de données, eXp comptait plus de 6,000 XNUMX connexions.
- L'entité agent avait plus de 140 attributs. La meilleure pratique est d'en avoir 20.
- L'entité avait sept attributs calculés. Ainsi, chaque fois qu'un utilisateur chargeait des informations sur un agent, l'application calculait environ 126,000 18,000 champs pour XNUMX XNUMX agents.
- Le processus d'une transaction immobilière est très varié : il va de la signature des documents et des contrats au suivi de la conformité, en passant par la création de fichiers d'audit, etc. Avec cinq à six minutes pour traiter une transaction immobilière, soit environ 100 transactions par jour, eXp faisait travailler ses collaborateurs toute la journée, du lundi au dimanche, pour traiter ces transactions.
Défis d'hébergement : voici Thanos
eXp Enterprise a demandé beaucoup de travail ressources cloud. eXp a initialement hébergé l'application sur le plus grand conteneur disponible sur Mendix Cloud v3. Avec 2,000 XNUMX utilisateurs par jour et une myriade de fonctionnalités, ils ont rapidement dépassé ses capacités.
Pour résoudre ce problème, eXp a migré l'application vers Magneto, le plus grand conteneur sur Mendix Cloud v4. À 90 % d'utilisation des ressources cloud, Magneto semblait fonctionner. Mais eXp a rapidement épuisé ce conteneur également. Peu de temps après, Mendix a créé Thanos, un conteneur cloud que Ledwith utilisait pour héberger eXp Enterprise et son architecture de microservices d'entreprise.
Repousser les limites de Cloud Foundry
Lorsque Mendix Cloud Foundry mis à niveau pour le Mendix plateforme, tout s'est bien passé pour tous Mendix utilisateurs, à l'exception d'eXp Realty, dont l'application a cassé Cloud Foundry.
eXp lancerait l'application et, en raison du nombre de fonctionnalités, liens, et les utilisateurs de l'application échouaient. Comme le dit Ledwith, « Notre application se démarrait, tous nos utilisateurs l'utilisaient, puis elle plantait. Nous la redémarrions et ils recommençaient à le faire toutes les deux heures environ. »
Selon Ledwith, l'analyse des causes profondes qu'il a reçue de la Mendix L'équipe Cloud a déclaré que 1,000 XNUMX threads étaient bien au-delà de ce qui était considéré comme raisonnable sur le Mendix Plateforme, donc cela n'a pas été détecté lors des tests. eXp Enterprise avait, à son apogée, 1,250 XNUMX threads exécutés toute la journée, tous les jours. Ledwith a dû reconsidérer la refactorisation de l'application pour réduire le nombre de threads.
Du « tout de suite » au « bon moyen » — Microservices
Une équipe d'ingénieurs composée d'environ 80 développeurs, dont 30 professionnels à temps plein Mendix développeurs—ont soutenu la croissance massive d'eXp Enterprise. Bien qu'eXp aurait pu continuer à développer son équipe pour prendre en charge l'application, ils ont vite réalisé que ce processus n'était pas évolutiveeXp a également essayé d'autres options comme l'achat de plus de conteneurs cloud, le refactoring et l'essai de l'architecture hub and spoke pour améliorer la situation, mais aucune d'entre elles ne s'est avérée être une solution à long terme.
La direction a donné deux semaines à l'équipe de Ledwith pour effectuer des recherches et proposer une solution viable. Ils ont opté pour les microservices.
La bonne méthode n°1 | Obtenir l'adhésion
Alors que Ledwith et son équipe modifiaient l’infrastructure technologique, il était important pour eux de comprendre les problèmes de l’entreprise et de obtenir l'adhésion non seulement de la part de l'équipe technique ou de la direction, mais également d'équipes comprenant des experts en ingénierie, en produits et en la matière.
En fait, Ledwith et son équipe ont passé près de deux mois à socialiser l'idée des microservices avec différentes équipes commerciales. La contribution des équipes commerciales a été essentielle pour Ledwith afin de garantir que les changements se concentrent sur ce dont l'entreprise a réellement besoin et sur ce qui lui apporte de la valeur.
La bonne voie n° 2 | Une approche à trois volets
Ledwith a élaboré une stratégie à trois volets pour mettre en œuvre des microservices.
Objectifs stratégiques
- Aidez l’entreprise à atteindre 100,000 XNUMX agents et favorisez l’innovation.
- Soutenez des milliers de intégrations tierces pour les données clients, les annonces et les données financières dont une société immobilière a besoin pour aider ses agents à vendre.
Principes architecturaux
- Guide d'aide à l'architecture gouvernance et réduisez la complexité – utilisez les bons outils pour le bon objectif pour un développement et un retour d’information rapides
Conception et livraison
- Limitez le code partagé afin que différentes équipes puissent apporter des modifications à leur partie des applications sans affecter les autres équipes. Si quelque chose était commun à d'autres équipes, elles utilisaient la boutique d'applications interne pour partager le module commun.
- Suivez le cadre CI/CD.
La bonne voie #3 | L'équipe Innovations
eXp a renforcé l'équipe de fonctionnalités agile, composée d'un chef de produit, de développeurs et de spécialistes de l'assurance qualité, en créant une équipe d'innovation qui comprenait des membres de l'entreprise. L'équipe commerciale était là pour examiner la situation dans son ensemble : comment créer de la valeur, augmenter les revenus, réduire le taux de désabonnement et rechercher des opportunités d'automatisation.
L'équipe d'innovation est propriétaire des services qu'elle a développés. Désormais, lorsque l'équipe passe en production, elle n'a pas de relais vers une équipe opérationnelle ou une équipe de maintenance, mais elle en est propriétaire tout au long de la production et de la maintenance.
La bonne voie n°4 | L'état d'esprit des microservices d'entreprise
Selon Ledwith, l'adoption d'un état d'esprit approprié a été l'ingrédient le plus important pour réussir tout au long du processus de réarchitecture. La fourniture de logiciels de classe entreprise avec une réelle valeur commerciale nécessite de la planification, du talent, de la contribution, de la logique, Réactions, et une exécution minutieuse avec une concentration constante sur les besoins réels de l’entreprise.