eXp Realty wechselt zur Enterprise-Microservices-Architektur

Wann ist der Umstieg auf eine Microservices-Architektur sinnvoll? Diese Frage stellen sich viele Unternehmen, die ihre bestehende Software-Technologiearchitektur bewerten, um agiler zu werden.

Als Branche ist der Immobiliensektor lokal. Jeder Staat betreibt die gleiche Art von Geschäft, aber auf unterschiedliche Weise. eXp Realty, dem sechstgrößten Immobilienmakler in den USA und ersten Cloud-basierten Immobilienunternehmen der Welt, bedeutete dies eine Aktualisierung seiner unternehmenskritischen Geschäftsanwendung eXp Enterprise.

eXp-Agenten, Auftragnehmer und Mitarbeiter verwenden eXp Enterprise, eine Cloud-basierte Anwendung entwickelt auf der Mendix  von Quibim, um Kerngeschäftsaktivitäten wie Onboarding und Deal-Registrierung durchzuführen. eXp hat die App zunächst auf einer monolithischen Architektur aufgebaut.

Um jedoch wettbewerbsfähig zu bleiben, erkannte Steve Ledwith, VP of Engineering bei eXp Realty, dass die Anwendung von einer monolithischen Architektur auf Microservices umgestellt werden musste. Diese Umstrukturierung war ein gewaltiges Unterfangen für das Unternehmen, da eXp in allen 50 Bundesstaaten tätig ist. Doch durch die Entwicklung einer Vision, die Einbindung aller Beteiligten und die Befähigung seiner Entwickler konnte eXp diese geschäftskritische Anwendung auf Microservices umstellen.

Die Notwendigkeit einer Veränderung auf Unternehmensebene

Im Laufe der Jahre hat eXp sein Geschäft von 2,500 Agenten auf 18,000 ausgebaut. Damit stiegen auch die Funktionen, die Benutzerbasis und die Hosting-Anforderungen von eXp Enterprise, was zu einer starken Technische Schulden die Ledwith ansprechen musste.

Der richtige Weg oder sofort?

Zum Zeitpunkt der Markteinführung hatte eXp Enterprise 30 Funktionen. In weniger als zwei Jahren fügte eXp der Anwendung 1,700 Funktionen hinzu, wobei 2,000 Benutzer die App täglich nutzten. Die Verwaltung dieser Funktionen bei einer so großen Benutzerbasis erforderte, was Ledwith als „sofortige“ Ansätze oder Ad-hoc-Entwicklungen der App bezeichnete, um unmittelbare Geschäftsanforderungen zu erfüllen. Ledwith fasst dieses Problem am besten zusammen, indem er sagt:

„Statt es richtig zu machen, haben wir es also sofort gemacht und es fehlte stark an Input“, sagt Ledwith.

Für ein Datenbankdomänenmodell ist die Mendix-way schreibt ein sauberes Modell vor – ein oder zwei Entitäten und Module. Aber das Agentendatenbank-Domänenmodell von eXp, das Informationen über die Agenten enthält, war eng gekoppelt.

Schauen wir uns einige Zahlen an:

• In einem Bereich der Datenbank hatte eXp über 6,000 Verbindungen.
• Die Agentenentität hatte mehr als 140 Attribute. Die beste Vorgehensweise sind 20.
• Die Entität hatte sieben berechnete Attribute. Jedes Mal, wenn ein Benutzer Agenteninformationen lud, berechnete die App also etwa 126,000 Felder für 18,000 Agenten.
• Der Prozess einer Immobilientransaktion ist vielfältig und reicht von der Unterzeichnung von Dokumenten und Verträgen über die Einhaltung von Vorschriften bis hin zur Erstellung von Prüfdateien und vielem mehr. Da die Bearbeitung einer Immobilientransaktion bei rund 100 Transaktionen pro Tag fünf bis sechs Minuten dauert, waren die Mitarbeiter von eXp von Montag bis Sonntag den ganzen Tag damit beschäftigt, diese Transaktionen abzuwickeln.

Hosting-Herausforderungen: Hier kommt Thanos

eXp Enterprise forderte schwere Cloud-Ressourcen. eXp hostete die Anwendung zunächst auf dem größten verfügbaren Container auf Mendix Cloud v3. Mit 2,000 Benutzern pro Tag und einer Vielzahl von Features und Funktionen waren die Kapazitäten bald erschöpft.

Um dieses Problem zu lösen, migrierte eXp die App zu Magneto, dem größten Container auf Mendix Cloud v4. Bei 90 % der Cloud-Ressourcennutzung schien Magneto zu funktionieren. Aber eXp erschöpfte auch diesen Container schnell. Bald darauf Mendix hat Thanos erstellt, einen Cloud-Container, der von Ledwith zum Hosten von eXp Enterprise und seiner Enterprise-Microservices-Architektur verwendet wird.

Die Grenzen der Cloud Foundry erweitern

Wann Mendix aktualisierte Cloud Foundry für die Mendix Plattform, es lief reibungslos für alle Mendix Benutzer, mit Ausnahme von eXp Realty, deren Anwendung Cloud Foundry zum Absturz brachte.

eXp würde die Anwendung hochfahren, und aufgrund der Anzahl der Funktionen, Verbindungen, und bei Benutzern stürzte die App ab. Ledwith sagt: „Unsere Anwendung startete, wir ließen alle unsere Benutzer darauf laufen und dann stürzte sie ab. Und wir starteten sie neu und sie stürzten etwa alle zwei Stunden wieder ab.“

Laut Ledwith erhielt er eine Ursachenanalyse von der Mendix Das Cloud-Team gab an, dass 1,000 Threads weit über dem lagen, was auf der Mendix Plattform, daher wurde es beim Testen nicht entdeckt. eXp Enterprise hatte in der Spitze 1,250 Threads, die den ganzen Tag über liefen. Ledwith musste eine Umstrukturierung der Anwendung in Betracht ziehen, um die Anzahl der Threads zu verringern.

Von „Jetzt sofort“ zu „Richtig“ – Microservices

Ein Engineering-Team von rund 80 Entwicklern – 30 davon sind Vollzeit-Profis Mendix Entwickler – unterstützten das massive Wachstum von eXp Enterprise. Obwohl eXp sein Team zur Unterstützung der Anwendung weiter hätte aufbauen können, erkannten sie bald, dass dieser Prozess nicht skalierbareneXp probierte auch andere Optionen aus, wie den Kauf weiterer Cloud-Container, Refactoring und die Hub-and-Spoke-Architektur, um die Situation zu verbessern, aber keine davon erwies sich als langfristige Lösung.

Das Management gab Ledwiths Team zwei Wochen Zeit, um zu recherchieren und eine praktikable Lösung vorzulegen. Sie entschieden sich für Microservices.

Richtiger Weg Nr. 1 | Holen Sie sich Zustimmung

Als Ledwith und sein Team die technologische Infrastruktur veränderten, war es für sie wichtig, die geschäftlichen Schwachstellen zu verstehen und kaufen nicht nur vom Technikteam oder Management, sondern auch von Teams aus den Bereichen Entwicklung, Produkte und Fachexperten.

Tatsächlich verbrachten Ledwith und sein Team fast zwei Monate damit, die Microservices-Idee mit verschiedenen Geschäftsteams bekannt zu machen. Der Input der Geschäftsteams war für Ledwith von entscheidender Bedeutung, um sicherzustellen, dass sich die Änderungen auf die wirklichen Bedürfnisse des Unternehmens konzentrieren und Mehrwert liefern.

Der richtige Weg Nr. 2 | Ein dreigleisiger Ansatz

Ledwith entwickelte eine dreigleisige Strategie zur Implementierung von Microservices.

Strategische Ziele

• Unterstützen Sie die Skalierung Ihres Unternehmens auf 100,000 Agenten und ermöglichen Sie Innovationen.
• Unterstützen Sie Tausende von Integrationen von Drittanbietern für Kunden-, Angebots- und Finanzdaten, die ein Immobilienunternehmen benötigt, um seinen Maklern beim Verkauf zu helfen.

Architekturprinzipien

• Hilfe-Leitfaden mit Architektur Governance und reduzieren Sie die Komplexität – verwenden Sie die richtigen Werkzeuge für den richtigen Zweck für schnelle Entwicklung und Feedback

Design und Lieferung

• Beschränken Sie den gemeinsam genutzten Code, damit verschiedene Teams Änderungen an ihrem Teil der Apps vornehmen können, ohne andere Teams zu beeinträchtigen. Wenn andere Teams etwas gemeinsam hatten, nutzten sie den internen App Store, um das gemeinsame Modul zu teilen.
• Befolgen Sie das CI/CD-Framework.

Der richtige Weg #3 | Das Innovations-Team

eXp erweiterte das agile Feature-Team, das aus einem Produktmanager, Entwicklern und QA-Spezialisten bestand, und schuf ein Innovationsteam, das auch Mitglieder aus dem Unternehmen umfasste. Das Business-Team war da, um das Gesamtbild zu betrachten – wie man Mehrwert liefert, den Umsatz steigert, die Fluktuation reduziert und nach Möglichkeiten zur Automatisierung sucht.

Das Innovationsteam war Eigentümer der von ihm entwickelten Dienste. Wenn das Team nun mit der Produktion beginnt, muss es die Dienste nicht an ein Betriebs- oder Wartungsteam übergeben, sondern behält sie während der gesamten Produktion und Wartung.

Der richtige Weg #4 | Die Enterprise Microservices-Denkweise

Laut Ledwith war die richtige Einstellung die wichtigste Voraussetzung für den Erfolg während des gesamten Re-Architektur-Prozesses. Die Bereitstellung von Enterprise-Software mit echtem Geschäftswert erfordert Planung, Talent, Input, Logik, Feedbackund eine sorgfältige Ausführung mit ständigem Fokus auf das, was das Unternehmen wirklich braucht.