# Shoprockets Weg zu Microservices, Teil 1: Was ich beim Zerlegen des Monolithen falsch gemacht habe > Ein Beitrag des Engineering-Teams aus den frühen Shoprocket-Jahren über den ersten Versuch, einen Service aus einem PHP-Monolithen herauszulösen. Warum ich den falschen ersten Service gewählt habe, was enge Kopplung mich gelehrt hat und den Rat von Newman, den ich früher hätte beherzigen sollen. Winston Berty - 17. März 2016 - 5 Min. Lesezeit Ein paar Monate nach meinem Start bei Shoprocket wurde ich langsam frustriert. Wir hatten eine PHP-Anwendung, an der ein kleines Team fähiger Entwickler arbeitete, verteilt über den ganzen Globus, und mir kam es so vor, als zögen Bugfixes weitere Bugs nach sich, als wäre die Integration neuer Features nicht so einfach, wie sie sein sollte, und als wären Deployments selten und nervenaufreibend. Der Grund: stark gekoppelter Code. Wir hatten eine monolithische Anwendung, fast alles in einem einzigen GitHub-Repository. Updates oder Fixes an einem Feature erforderten oft Änderungen an mehreren Stellen. Zum Testen gab es einen Peer-Review-Prozess, bei dem mindestens zwei weitere Entwickler einen Branch abnehmen mussten, bevor er in master gemergt und deployt wurde. Das alles führte dazu, dass es schwer war, die schuldige Änderung zu finden, wenn sich ein Bug eingeschlichen hatte. Sobald wir sie gefunden hatten, durchlief der Fix denselben Prozess, und die gesamte Anwendung musste neu deployt werden. Als eifriger junger Entwickler, der immer nach dem Neuesten sucht, dachte ich beim Stoßen auf Microservices, das würde all unsere Probleme lösen. ## Was ich unter Microservices verstand Es gibt keine formale Definition von Microservices, aber aus meiner Recherche nahm ich mit, dass Microservice-Architektur eine Art ist, Software als verteilte Systeme unabhängiger Services zu entwerfen, jeder hochspezialisiert und mit eigenem Lebenszyklus. Für eine ausführliche Einführung ist Martin Fowlers [Artikel](https://martinfowler.com/articles/microservices.html) hervorragend. Zwei Aspekte haben mich überzeugt. Erstens die Idee, die Anwendung in Services mit strikten Grenzen zu zerlegen. Das senkt die Wahrscheinlichkeit, dass Logik, die zu einem Geschäftskontext gehört, zwischen Komponenten durchsickert, weil die Schnittstellen zwischen den Grenzen sorgfältig geplant werden müssen. Es ist nicht so einfach wie lokale Funktionsaufrufe. Zweitens kann jede Komponente ihren eigenen, unabhängigen Lebenszyklus haben. Teams können ihren Code besitzen und den Stack wählen, der am besten zum Service passt, und Änderungen lassen sich Service für Service deployen und zurückrollen, ohne den Rest zu beeinflussen. Ich war überzeugt. Shoprocket würde den Monolithen aufbrechen. Das ist Teil 1 einer kurzen Serie, die diesen Weg begleitet. Ich hoffe, dass Leser, die einen ähnlichen Übergang planen oder gerade durchlaufen, aus unseren Erfolgen und Fehlern lernen. ## Die erste Herausforderung war menschlich, nicht technisch Ich musste den Rest des Teams von der Idee überzeugen. Sie waren neugierig, teilten die Begeisterung aber nicht und wollten in dieser frühen Phase des Produkts ungern Entwicklungsstunden hergeben. Zum Glück wollte der CTO, dass ich mir unser Session-Management ansehe, also nutzte ich den Moment: Ich überzeugte ihn, dass ich einen Session-Service abspalten könnte. Im Rückblick war das eine schlechte Wahl für den ersten Service. Unser Produkt enthält ein JavaScript-Widget, das [E-Commerce auf jeder Website ermöglicht](https://v3.shoprocket.io/de/funktionen/auf-jeder-website-verkaufen.md). Wir behandeln Sessions als Ressource und speichern Session-Informationen in der Datenbank, um Warenkorbabbrüche und andere KPIs zu analysieren. Aber diese Ressource ist nicht so greifbar wie etwa Bestellungen oder Positionen, und wir nutzten Sessions bei fast jeder Änderung des Anwendungszustands. Das bedeutete, dass der Service zwangsläufig viel mit dem Rest der Anwendung kommunizieren würde, was ich nicht vorhergesehen hatte und was meine Aufgabe erschwerte. ## Was ich beim tatsächlichen Bauen gelernt habe Ich vertiefte meine Recherche. Neben Fowler erwies sich Sam Newmans **Building Microservices** als unverzichtbare Quelle. Newmans Rat war rückblickend der Rat, dem ich hätte folgen sollen: Zuerst die bestehende Anwendung in Module umbauen, die die Bounded Contexts der Domäne abbilden. Erst wenn die Entwickler mit den Grenzen zufrieden sind, *dann* Module in eigene Services abspalten. Der Grund: Module mit schlechten Grenzen lassen sich viel leichter zerlegen und neu schreiben als ganze Services mit all ihrem zusätzlichen Infrastrukturcode und ihren persistenten Ressourcen. Ich habe diesen Rat nicht befolgt. Begierig darauf, eine eigene Komponente zu bauen, zog ich den Session-Service durch. Ich wählte einen Stack, der sich nur geringfügig von dem des Monolithen unterschied, und fing an zu bauen. Der Service selbst war schnell fertig: Ein paar Wochen reichten für eine eigenständige Anwendung mit REST-API. Dort lag die Schwierigkeit nicht. Schwierig war es, den Service mit dem Monolithen sprechen zu lassen. Das Session-Management stellte sich als eng mit dem Rest der Codebasis verflochten heraus. Funktionsaufrufe durch API-Aufrufe zu ersetzen war mühsame Arbeit. Weil der Session-Service und der Monolith getrennte Datenbankschemas hatten, musste ich jede Logik im Monolithen umschreiben, die Session-Ressourcen aus der alten Datenbank nutzte, und Daten an der Anwendungsgrenze umstrukturieren, damit Clients wie unser JavaScript-Widget kompatibel blieben. Die Integration dauerte länger als das Bauen. Und dabei war der Großteil des Overheads, den Microservices normalerweise mitbringen, noch gar nicht enthalten: Service Discovery, Logging, Monitoring, verteiltes Tracing. Schlimmer noch: Enge Kopplung bedeutete, dass sich Änderungen über viele Bereiche des Codes verteilten. Da das Team in dieser Zeit parallel weitergearbeitet hatte, hätte das Mergen und der Produktivgang des Session-Service deutlich mehr Abstimmung erfordert, als ich eingeplant hatte. ## Die ehrliche Bilanz Der Service geht vielleicht bald in Produktion. Aber ich habe jetzt das Gefühl, dass ich Newmans Rat hätte befolgen und meine Anstrengungen zuerst in die Modularisierung der bestehenden Anwendung stecken sollen. Der Nutzen eines einzelnen Services, der für sich allein lebt, ist gering. Der echte Nutzen entsteht, wenn man das Ganze aufteilt, zumindest in grobkörnige Services, die möglichst wenig miteinander kommunizieren. Dafür braucht es gut durchdachte Komponentengrenzen, und so weit waren wir noch nicht. Ich bin weiterhin von Microservices als Idee überzeugt. Meinen Versuch sehe ich als nützliches Experiment. Ich habe viel über Anwendungsarchitektur, Domänenmodellierung und REST-Prinzipien gelernt, und diese Erkenntnisse hatten Folgewirkungen auf andere Teile unseres Codes. Für alle, die einen ähnlichen Übergang erwägen, meine ehrlichen Empfehlungen: - Lies dich so gründlich wie möglich in das Thema ein, bevor du dich festlegst - Schieb die Arbeit auf, bis du wirklich sicher mit deiner bestehenden Codebasis und deinem Domänenmodell bist - Denk daran, dass es andere Wege gibt, einem Monolithen Stabilität und Robustheit zu geben. Automatisierte Unit- und Funktionstests helfen enorm. Test-Driven Development verringert Regressionen. Horizontale Skalierung macht Deployments weniger schmerzhaft - Fang damit an, deinen Monolithen zu modularisieren, bevor du Services herauslöst Shoprocket wird seinen Weg fortsetzen. In Teil 2 wird es interessanter. --- *Ursprünglich als erster Beitrag einer kurzen Serie erschienen, die Shoprockets frühe Migration weg von einem PHP-Monolithen dokumentiert. Der gesamte Weg, einschließlich der in späteren Iterationen korrigierten Fehler, hat sich seitdem durch jeden großen Neubau der Plattform fortgesetzt.* --- - HTML version: https://v3.shoprocket.io/de/blog/shoprocket-microservices-teil-1-monolith-zerlegen-fehler - Language: Deutsch (de) - Also in: [العربية](https://v3.shoprocket.io/ar/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [English](https://v3.shoprocket.io/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Español](https://v3.shoprocket.io/es/blog/shoprocket-microservicios-parte-1-lo-que-hice-mal-monolito.md), [Français](https://v3.shoprocket.io/fr/blog/shoprocket-vers-les-microservices-partie-1-decouper-le-monolithe.md), [עברית](https://v3.shoprocket.io/he/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [हिन्दी](https://v3.shoprocket.io/hi/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Bahasa Indonesia](https://v3.shoprocket.io/id/blog/perjalanan-shoprocket-menuju-microservices-bagian-1-salah-memecah-monolit.md), [Italiano](https://v3.shoprocket.io/it/blog/viaggio-di-shoprocket-verso-i-microservizi-parte-1-cosa-ho-sbagliato-sul-monolite.md), [日本語](https://v3.shoprocket.io/ja/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Lietuvių](https://v3.shoprocket.io/lt/tinklarastis/shoprocket-kelione-i-mikropaslaugas-1-dalis.md), [Norsk](https://v3.shoprocket.io/nb/blogg/shoprockets-vei-mot-mikrotjenester-del-1-hva-jeg-tok-feil-av.md), [Nederlands](https://v3.shoprocket.io/nl/blog/shoprocket-microservices-deel-1-monoliet-opknippen.md), [Polski](https://v3.shoprocket.io/pl/blog/droga-shoprocket-do-mikroserwisow-czesc-1-rozbijanie-monolitu.md), [Português](https://v3.shoprocket.io/pt/blog/jornada-do-shoprocket-para-microsservicos-parte-1-o-que-errei-ao-quebrar-o-monolito.md), [Română](https://v3.shoprocket.io/ro/blog/drumul-shoprocket-spre-microservicii-partea-1-ce-am-gresit-cu-monolitul.md), [Русский](https://v3.shoprocket.io/ru/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [ไทย](https://v3.shoprocket.io/th/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Türkçe](https://v3.shoprocket.io/tr/blog/shoprocket-mikroservis-yolculugu-1-monoliti-parcalarken-yanlis-yaptiklarim.md), [中文](https://v3.shoprocket.io/zh/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md)