Morningstar.com: Vom Monolithen zu Serverless

Die Gründung von Morningstar im Jahr 1984 war für den damals erst 27 Jahre alten Börsenanalysten Joe Mansueto vor allem eines: persönliche Überzeugung. Mansueto wollte die Informationen, die Finanzdienstleister zur Beratung ihrer Kunden nutzten, nun diesen selbst verfügbar machen. Mit lediglich 80.000 US-Dollar Startkapital, dafür aber umso mehr Leidenschaft für sein Ziel und einem kleinen, engagierten Team startete der junge Visionär noch aus seinem Apartment durch. 

Heute zählt Morningstar über 5.000 Mitarbeiter, ist in 27 Ländern aktiv, berät zu über 600.000 Investments und verwaltet Anlagen im Wert von mehr als 200 Milliarden US-Dollar. Erreicht wurde dieses Wachstum durch stetige Weiterentwicklung von kundenorientierten Investment-Produkten und -Services.

Im Zentrum des Unternehmensportfolios steht Morningstar.com als Kundenportal für das gesamte Produkt- und Serviceangebot. 2018 erhielten die Tech-Teams ein wegweisendes Doppelmandat rund eine Neukonzipierung der gesamten Website: Sowohl Geschwindigkeit als auch Stabilität sollten auf ein gänzlich neues Niveau gebracht werden, dies zudem in lediglich sieben Monaten. Man ergriff die Gelegenheit beim Schopfe, hegte man doch selbst schon lange den Wunsch einer neu aufgelegten, transparenten Website-Infrastruktur.

Morningstar.com Senior Software Engineer Clay Gregory zu den Prioritäten: „Unser oberstes Ziel war ein einfacheres System. Unsere Website ist um redaktionelle Inhalte herum aufgebaut mit Tools, die Einzelinvestoren bei der Marktanalyse und ihren Investment-Entscheidungen helfen. Diese Zielvorgabe eröffnete uns die Möglichkeit, unsere gesamte technische Ausrichtung grundlegend zu durchleuchten. Das wollten wir natürlich auch konsequent nutzen, unser System viel transparenter machen, Änderungen und ihre Auswirkungen endlich klarer nachvollziehen können.“

Zum Zeitpunkt dieser strategischen Weichenstellung setzte die Anwendung von Morningstar.com vornehmlich auf ein Enterprise Content Management System. Hinzu kamen in einer Java-Anwendung gehostete Backend-Services.

Die bestehende Architektur hatte sich jedoch in der Vergangenheit anfällig für mehrere höchst disruptive Ausfälle gezeigt und wies generell einige erhebliche Schwächen auf: So konnten Traffic-Spitzen nur unzureichend skaliert, Performance-Probleme nur schleppend identifiziert und behoben und neue Produkte und Features nur mit langer Vorlaufphase eingeführt werden.

Angesichts der ambitionierten technischen Ziele und vor dem Hintergrund der dem Investmentmarkt eigenen Workload-Volatilität kristallisierte sich AWS Lambda rasch als Ideallösung heraus.

War das Legacy-System in vielerlei Hinsicht Innovationsbremse gewesen, konnte man sich durch Replatforming auf eine Serverless-Architektur mit AWS Lambda, API Gateway, S3 und CloudFront um ein Vielfaches adaptiver aufstellen. Die Anwendungen und internen Services des Unternehmens erhielten so nun endlich die erforderliche Geschwindigkeit, wurden in operativer und in Kostenhinsicht effizienter. 

„Wir waren überrascht, wie einfach die Migration zu AWS Lambda letztlich war“, zeigt sich Morningstar.com Senior Software Engineer Zach Erdmann erfreut. „Unsere Benchmarks waren ja Managed Services und eine Enterprise-Anwendung à la Monolith, da waren diese Deployment-Cycles wirklich eine ganz andere Dimension für uns. Unsere CI-Pipeline ist stets voll – wenn wir eine Version aus der Entwicklung innerhalb von 20 Minuten in einen Kandidaten für die Produktion ummünzen können, macht das natürlich einen ganz gewaltigen Unterschied für unser Angebot.“

Je größer ein Unternehmen, desto mehr ist seine Architektur natürlich auch über einen langen Zeitraum ge- und auch ein Stück weit verwachsen. Auch Morningstar bildete hier freilich keine Ausnahme. Bestehende Java- und .NET-Services sowie APIs machten die Entwicklung einer Greenfield-API innerhalb von sieben Monaten zu einem gänzlich unrealistischen Unterfangen.

Gregory hierzu: „Unser Angebot ist einer breiten Öffentlichkeit zugänglich. Bisweilen behalten wir dabei bestimmte Komponenten bei, da sie noch eine gewisse Verwendung erfahren, wenngleich für einen Rebuild keine Veranlassung besteht. Im Laufe der Zeit sammeln sich da im Stack natürlich so einige Sprachen und Anwendungen an, die es nach wie vor zu unterstützen gilt. Mit AWS Lambda konnten wir all dies endlich sauber in einem Kontext verknüpfen.“

Gregory und Erdmann entschieden sich daher, Komponenten zu identifizieren und abzukoppeln, die anhand von AWS Lambda-Funktionen neu erstellt oder ersetzt werden konnten. Als Bindeglieder zwischen den bestehenden und komplett neuen Services schrieb man Funktionen für die Businesslogik zwischen UX, Markt- und Benutzerdaten und Content.

Als Teil dieser neuen Architektur setzt Morningstar unter anderem auf CloudFront. Über das Content-Netzwerk werden etwa Inhalte aus S3 Buckets mit statischen Site-Assets bereitgestellt. Hinzu kommen eine CMS-gestützte Site für Corporate Marketing, verschiedenste interne Services und Lambda-Funktionen mit API Gateway für dynamische Inhalte und Daten zu User Events. Per Multitier Cache nutzt CloudFront regionale Edge Caches zur Verbesserung von Latenz und Load-Reduzierung bei seinen Ursprungsservern. Im Backend kommt API Gateway als elementare Skalierungskomponente zur Verarbeitung und zum Routing paralleler API-Calls für Lambda-Funktionen zum Einsatz.

Per se waren Monitoring-Technologien in Form verschiedenster Tools zwar schon in der Vergangenheit im Unternehmen zum Einsatz gekommen, beispielsweise mit New Relic Synthetics für Health-Checks. Gleichzeitig war es aber bei einer eher unsystematischen Verwendung geblieben. Im Stack selbst herrschte dabei wortwörtlich Intransparenz – mit Systemabläufen, die für niemanden so recht end-to-end nachvollziehbar waren. 

Erdmann hierzu: „Schon bei unserem Legacy-System kannten wir Monitoring, nur setzten wir es nicht konsequent ein. Es war einfach nicht Bestandteil unserer Strategie oder unserer Architektur. Als wir also mit dem Replatforming von Morningstar.com begannen, wollten wir alle Komponenten instrumentieren und so alle Abläufe in unserer Anwendung in ihrer Gänze nachvollziehen können.“

Morningstar.com hat für das Unternehmen ganz zentralen Storefront-Charakter, verarbeitet Daten sowohl aus internen als auch aus externen Tools und Services. Tritt ein Problem für einen Benutzer von Morningstar.com zutage, stammt die Fehlerursache womöglich aus einem Upstream-Bereich.

„New Relic war auch deshalb für uns so relevant, da wir eine Umgebung mit Komponenten ganz diverser Art haben“, erläutert Gregory. „Nicht alle Teams im Unternehmen setzen auf die Cloud, wir benötigen hier also ganz unterschiedliche Herangehensweisen. Daher ist es absolut entscheidend für uns, dass wir unser Monitoring für jede Plattform einsetzen und dabei Transparenz und Insights generieren können.“

Dank New Relic kann das Team von Morningstar.com alle Details zu seinen Lambda-Funktionen visualisieren, Tracing und Alerting bei Bedarf zur Fehleranalyse und -behebung auf Ebene einzelner Aufrufe durchführen. Im Rahmen der aus unterschiedlichen Anwendungen, Laufzeiten und Business APIs bestehenden Umgebung war jedoch Transparenz für das gesamte System gefragt und nicht nur für die Serverless-Komponenten.

„Einer der größten Erfolgsfaktoren bei diesem Replatforming: Über eine zentrale Komplettansicht sehen wir jetzt alle relevanten Abläufe auf Morningstar.com. Dieses fantastische Ergebnis war auch einer der Hauptgründe, warum wir unsere Zusammenarbeit mit New Relic unternehmensweit ausgebaut haben“, beschreibt Erdmann. „Jede noch so kleine Performance-Schwankung sehen wir innerhalb von Sekunden. Mit New Relic erkennen wir direkt, wenn etwas unserer Aufmerksamkeit bedarf, und können sofort reagieren.“

Nicht nur den Zeitaufwand zur Identifikation und Behebung von Problemen konnte Morningstar.com drastisch reduzieren, auch Downtime ist nunmehr zu einer höchst seltenen Randerscheinung geworden. Waren zuvor noch umfassende monatliche Ausfälle gang und gäbe, kam es seit dem Replatforming zu keinem einzigen.

„Jeden Monat präsentieren die Teamleiter in unternehmensweiten Incident Reviews die signifikantesten Ausfälle auf ihrer Seite im vorangegangenen 30-Tage-Fenster“, erklärt Gregory. „Seit dem Replatforming von Morningstar.com und dem konsequenten Deployment von New Relic gab es hierzu schlicht nichts mehr zu berichten, was natürlich bis hoch zu unserem CTO auf großen Anklang stößt.“

Es liegt aber nur in der Natur der Sache, dass auch heute noch gelegentlich Probleme auftreten. Gregory und Team können diese nun aber direkt ausmachen und adressieren bzw. zur Behebung an das jeweilige Team übergeben – all dies lange, bevor sie Einfluss auf die UX nehmen oder die Website zum Absturz bringen können.

Das Morningstar.com Engineering-Team ist dank dieser Monitoring-Möglichkeiten in der Lage, neue Feature-Releases schneller umzusetzen, und kann sich zudem besser auf die Optimierung der UX konzentrieren.

„Wir sind ein recht kompaktes Team, dem seine Verantwortung für Produkt-Features sehr wichtig ist“, so Gregory. „Umso weniger Zeit wir also mit Engineering-Problemen verbringen müssen, desto mehr können wir in unsere Hauptaufgabe investieren – und die besteht darin, unseren Nutzern für sie relevante, hochwertige Ergebnisse zu liefern. Eben nicht Teil dieser ist die Wartung von Infrastruktur, und dank AWS und Monitoring mit New Relic muss das auch nicht sein.“

Dank Monitoring-Rückgrat zur Absicherung und neuer CI/CD-Pipeline sind Launches weitaus stressfreier als zuvor, die Beweglichkeit im Dev-Bereich dafür proportional höher. 

„Vor dem Replatforming und dem Deployment von Monitoring mit New Relic über die Website hinweg nahm unser QA-Prozess eine volle Woche in Anspruch. Und selbst dann waren wir einigermaßen nervös in Bezug auf unseren Release“, erinnert sich Gregory. „Wir haben ihn dann ganz bewusst erst zwischen 21 und 23 Uhr durchgeführt – also zu einer Zeit, als wir immer erfahrungsgemäß relativ wenige Seitenbesucher hatten. Jetzt sieht die Situation ganz anders aus: Unser Standard-Timing für Launches ist nunmehr 17 Uhr. 10 Minuten später können wir entspannt in den Feierabend gehen und uns sicher sein, dass alles glatt laufen wird.“

Seit dem Replatforming gab es noch keinen Anlass für ein Deployment-Rollback. „Wir können uneingeschränkt auf unseren Prozess, auf unser Monitoring vertrauen. Eine Service-Wiederherstellung ist für uns somit probater als ein Rollback. Dank New Relic richtet sich unser Blick also stets voraus, und das ist schon wirklich eine tolle Ausgangssituation.“

Für Gregory und Erdmann so überraschend wie bereichernd: Die teamübergreifende Kommunikation zwischen Engineering- und Business-Teams hat sich seit dem Replatforming und dem Monitoring mit Instrumentierung entscheidend verbessert.

Kunden- und nutzungsspezifische Metrics sind nun Bestandteil des Anwendungs-Monitorings, die Business-Teams nun mehr und mehr interessiert an den Zusammenhängen zwischen Applikationen und Geschäftsergebnissen. Edelmann hierzu: „New Relic vermittelt uns allen gemeinsam ein Kontinuum, in dem die Quantifizierung technischer Aspekte nicht nur für Engineers hilfreich ist, sondern für alle. Das Dashboard ist so zu einer enorm hilfreichen Informationsquelle für das gesamte Unternehmen geworden.“

Kostenloses Stack Monitoring mit 100 GB Daten pro Monat. Direkt unverbindlich starten.

Kostenlos registrieren