Shoprockets Weg zu Mikrodiensten: Teil 1

Ein paar Monate nach meinem Job bei Shoprocket begann ich, frustriert zu werden. Wir hatten eine PHP-Anwendung, an der unser kleines Team aus talentierten Entwicklern, die über den ganzen Globus verteilt waren, arbeitete. Warum war ich frustriert? Es schien mir, als würden Bugfixes mehr Bugs erzeugen, das Integrieren neuer Funktionen war nicht so einfach, wie es sein könnte, und Deployments waren selten und stressig. Der Grund für diese Probleme: hochgradig gekoppelte Codes.

Wir hatten eine monolithische Anwendung, und fast unser gesamter Codebase lag in einem einzigen Github-Repository. Updates oder Korrekturen an einer Funktion fanden oft an mehreren Stellen statt. Für Tests hatten wir einen Peer-Review-Prozess, bei dem mindestens zwei andere Entwickler einen Branch absegnen mussten, bevor er in master integriert und deployed wurde. Das bedeutete, dass es oft schwer war, die brechenden Änderungen zu finden, wenn Bugs unter dem Radar durchschlüpften. Und sobald wir das taten, mussten die Korrekturen denselben Prozess durchlaufen und die gesamte Anwendung musste neu deployed werden.

Als eifriger junger Entwickler, der immer nach dem Neuen suchte, dachte ich, dass dieses Architekturmodell all unsere Probleme lösen würde, als ich auf Microservices stieß. Es gibt keine formelle Definition von Microservices, aber aus meiner Recherche nahm ich mit, dass die Microservice-Architektur eine Möglichkeit ist, Softwareanwendungen als verteilte Systeme unabhängiger Dienste zu entwerfen, die jeweils hochspezialisiert und mit einem eigenen Lebenszyklus verfügen. Für Leser, die eine ausführlichere Einführung in das Konzept wünschen, empfehle ich Martin Fowlers ausgezeichneten Artikel.

Es gab viele Aspekte von Microservices, die mich interessierten, aber zwei besonders: Erstens die Idee, die Anwendung in Dienste mit sehr strengen Grenzen aufzuteilen. Dies verringert die Wahrscheinlichkeit, dass logikspezifische Teile für einen bestimmten Geschäftskontext zwischen den Komponenten durchkommen, da die Schnittstellen zwischen den Grenzen sorgfältig geplant werden müssen. Es ist nicht so einfach wie lokale Funktionsaufrufe zu machen; Zweitens kann jede Komponente ihren eigenen unabhängigen Lebenszyklus haben. Dies ermöglicht es den Teams, die Verantwortung für ihren Code zu übernehmen und einen Technologie-Stack zu verwenden, der am besten für den jeweiligen Dienst geeignet ist. Außerdem ermöglicht es eine feinere Kontrolle über die Anwendung, da Änderungen nacheinander an einem Dienst bereitgestellt werden können und ohne Einfluss auf den Rest der Anwendung zurückgesetzt werden können, wenn etwas schiefgeht.

Also war ich überzeugt. Shoprocket würde den Monolithen aufbrechen! Dies ist der erste Teil einer kurzen Serie von Blogbeiträgen, die diese Reise dokumentiert. Mein Hoffnung ist, dass Leser, die einen ähnlichen Übergang planen oder durchlaufen, von unseren Erfolgen und Misserfolgen lernen und sich besser vorbereitet fühlen, diese Herausforderung in ihren eigenen Projekten anzugehen.

Meine erste Herausforderung war nicht technisch, sondern menschlich. Ich musste der restlichen Mannschaft die Idee verkaufen. Sie schienen neugierig, teilten jedoch nicht dieselbe Begeisterung und waren unwillig, in dieser frühen Phase des Lebenszyklus unseres Produkts Entwicklungsstunden aufzugeben. Glücklicherweise wollte der CTO, dass ich uns mit unserem Sitzungsmanagement beschäftige, und ich nutzte die Gelegenheit, indem ich ihn überzeugte, dass ich einen Sitzungsdienst abspalten könnte.

Rückblickend war dies vielleicht keine gute Wahl für einen ersten Dienst. Unser Produkt enthält ein Javascript-Plugin, das E-Commerce auf jeder Website ermöglicht. Wir betrachten Sitzungen als Ressource und speichern Sitzungsinformationen in der Datenbank für eine detaillierte Analyse von KPIs wie der Warenkorbabbruchrate. Diese Ressource ist jedoch nicht so greifbar wie Bestellungen oder Positionen. Außerdem verwendeten wir die Sitzungsressource bei fast jeder Änderung des Anwendungszustands. Das bedeutete, dass der Dienst unvermeidlich den Austausch mit dem Rest der Anwendung intensiv haben würde, was ich nicht vorhergesehen hatte, was meine Aufgabe erschwerte.

Nachdem ich meinen Chef überzeugt hatte, intensivierte ich meine Recherche zu Microservices. Abgesehen von dem erwähnten Artikel fand ich auch Sam Newmans ‘Building Microservices’ als eine unschätzbare Ressource. Ich werde oft auf beide in meinen Beiträgen zurückkommen.

In seinem Buch empfiehlt Newman zuerst, eine bestehende Anwendung in Module umzustrukturieren, die die begrenzten Kontexte der Domäne widerspiegeln. Sobald die Entwickler zufrieden sind, können die Module dann in ihre eigenen Dienste aufgeteilt werden. Der Grund dafür ist, dass es viel einfacher ist, Module aufzubrechen und neu zu schreiben, wenn ihre Grenzen schlecht gewählt wurden, als gesamte Dienste mit all ihrem zusätzlichen Code und den persistenten Ressourcen aufzubrechen und neu zu schreiben. Aufgrund von Zeitbeschränkungen und meinem Eifer, eine eigene Komponente zu bauen, ging ich jedoch mit dem ersten Dienst weiter.

Ich wählte einen Stack, der nur geringfügig von dem abwich, den wir für unseren Monolithen verwendeten, und begann mit dem Bau. Der Bau selbst ging recht schnell vonstatten und dauerte einige Wochen, um eine eigenständige Anwendung mit einer REST-API zu produzieren. Erst dann begannen die eigentlichen Herausforderungen.

Ich musste den Dienst dazu bringen, mit dem Monolithen zu kommunizieren. An diesem Punkt lernte ich, wie eng das Sitzungsmanagement mit dem Rest des Codes gekoppelt war. Es dauerte eine Weile, bis ich bestehende Funktionsaufrufe aufschlüsseln und in API-Aufrufe umwandeln konnte. Das war knifflig. Da der Sitzungsdienst und der Monolith eigene Datenbankschemata hatten, musste ich jede Logik im Monolithen, die Sitzungsressourcen aus der alten Datenbank verwendete, umschreiben und die Daten an der Anwendungsgrenze umstrukturieren, um die Kompatibilität mit Clients wie unserem Javascript-Plugin aufrechtzuerhalten.

Die Integration des Dienstes in unsere bestehende Anwendung dauerte länger als das Schreiben des Dienstes selbst, und dies beinhaltete nicht eine Menge des zusätzlichen Aufwands, den Microservices normalerweise mitbringen, wie Dienstentdeckung, Logging und Monitoring. Darüber hinaus mussten aufgrund der engen Kopplung in vielen Bereichen des Codes Änderungen vorgenommen werden. Da das Team während dieser Zeit an verschiedenen Bereichen des Codes parallel arbeitete, wäre es erforderlich gewesen, viel mehr Arbeit in die Zusammenführung der Änderungen zu stecken und den Sitzungsdienst in die Produktion zu bringen.

Der Dienst könnte jedoch bald in die Produktion gehen, ich habe jedoch jetzt das Gefühl, dass ich Newmans Rat hätte folgen und meine Bemühungen darauf konzentrieren sollen, unsere bestehende Anwendung zu modularisieren. Der Vorteil, einen Dienst unabhängig zu haben, ist marginal. Der wahre Nutzen wird daraus resultieren, das Ganze auf mindestens grobgliedrige Dienste aufzuteilen, die so wenig wie möglich kommunizieren. Dies erfordert gut durchdachte Komponenten-Grenzen, und da sind wir noch nicht ganz angekommen.

Ich bin nach wie vor von der Idee der Microservices überzeugt und betrachte meinen Versuch, einen Dienst abzutrennen, als ein erfolgreiches Experiment. Ich habe in dem Prozess viel über Anwendungsarchitektur und Domänenmodellierung gelernt und mein Verständnis der REST-Prinzipien unter anderem verbessert. Diese haben sofortige Auswirkungen auf andere Bereiche unseres Codes gehabt.

Für Leser, die konvertieren möchten, würde ich dringend empfehlen, sich so viel wie möglich über das Thema zu informieren und die Arbeit aufzuschieben, bis man mit dem bestehenden Codebase und dem Domänenmodell sehr sicher ist. Es gibt andere Möglichkeiten, Stabilität und Resilienz in eine monolithische Anwendung einzuführen. Testgetriebenes Entwickeln und automatisierte Unit- und Funktionstests helfen enorm. Horizontales Scaling hilft auch, Deployments etwas reibungsloser zu gestalten.

Shoprocket wird seinen Weg zu Microservices fortsetzen. Wir freuen uns darauf, euch im Teil 2 mehr zu erzählen!