Über Monolithen und Microservices.

Einleitung

Seit etwa 2015 werden Microservices als der revolutionäre Weg verkauft, Unternehmen agiler und reaktionsfähiger zu machen. Als ultimative Lösung für moderne Softwareentwicklung angepriesen, haben Microservices unzählige Erfolgsgeschichten auf Plattformen wie YouTube generiert – oft wahrscheinlich mit einer gehörigen Portion Survivorship Bias. Eine ganze Industrie ist rund um Tools und Services für Microservices entstanden, und viele Softwareentwickler sind nach wie vor überzeugt, dass Microservices die Antwort auf alle Herausforderungen der Softwareentwicklung sind.

Aber Microservices können Ihr Unternehmen zerstören. Und meistens gibt es bessere Alternativen.

Folgende zwei Beiträge zu diesem Thema könnten Sie ebenfalls interessieren:

• Ein Vergleich zwischen Microservices und Monolithen
• Über modulare Monolithen

Meine Erfahrung

Nach meiner Erfahrung sind Microservices oft die falsche Wahl für die meisten Projekte. Die Einführung von Microservices kann:

• Die Produktivität Ihres Teams verringern
• Zu einem Zoo unwartbarer Technologien führen
• Zu zahlreichen schwer zu debuggenden Problemen führen
• Sehr langsam werden, da die Kommunikation von In-Memory auf netzwerkbasierte Kommunikation umgestellt wird

Was sind Microservices?

Microservices sind kleine, unabhängige Services, jeder mit seiner eigenen Domäne (hoffentlich), die über ein Netzwerk kommunizieren und oft auf Kubernetes laufen. Sie haben unabhängige Deployment-Zyklen und erfordern ein hohes Maß an Erfahrung und Können für eine effektive Implementierung.

Leider setzen viele Unternehmen Microservices aus den falschen Gründen ein und behandeln sie als Spielwiese für Entwickler, anstatt sich auf den Aufbau wertvoller Features zu konzentrieren. Das Ergebnis ist oft ein verteilter Monolith mit sehr starken Abhängigkeiten, die man von Anfang an nicht haben wollte.

Microservices können sinnvoll sein – z.B. in Szenarien, in denen bestimmte Teile des Codes extrem performant sein müssen und auf eigener Hardware laufen sollten. In solchen Fällen ergibt sich die Entscheidung, leistungsintensive Berechnungen in einzelne Services auszulagern, ganz natürlich.

Microservices um der Microservices willen zu erstellen, wird Sie in Schwierigkeiten bringen. Und nein – es ist keine gute Idee, mit einer Microservice-Architektur zu beginnen, weil sie Ihnen in 2 Jahren beim Skalieren helfen wird.

Das Microservice-Risiko

Microservices sind weder grundsätzlich gut noch schlecht; sie sind einfach ein Werkzeug, das entwickelt wurde, um spezifische Probleme zu lösen, die Sie wahrscheinlich nicht haben. Die Risiken umfassen:

• Schwieriger Aufbau und steile Lernkurve für neue Entwickler
• Schwieriges Debugging
• Schwer nachvollziehbare Kommunikation (Trace-ID in Ihren HTTP-Headern)
• Fehleranfällige und langsame HTTP-Kommunikation im Vergleich zur In-Memory-Kommunikation in Monolithen

Die Alternative: Der Monolith

Das Design Ihrer Anwendung als einzelne Einheit ist in den meisten Fällen oft die richtige Wahl, insbesondere für SaaS-Anwendungen. Dies ist die Standardarchitektur für fast jedes Web-Framework, einschließlich Play, Laravel und Ruby on Rails. An diesem Ansatz ist absolut nichts falsch, und die Dinge einfach zu halten, macht Sie nicht zu einem schlechten Entwickler. Sie können immer noch all Ihre Clean-Code-Fähigkeiten anwenden und die Dinge SOLID halten, Domain-Driven Design (DDD) nutzen und die Komponentenprinzipien aus Clean Architecture respektieren.

Vorteile von Monolithen

• Einfach zu debuggen
• Einfach zu warten
• Einfach zu deployen
• Trivial auf einem Entwicklerrechner einzurichten

Wenn Sie aus dem Monolithen herauswachsen

Sie haben immer die Möglichkeit, mehrere Anwendungen zu betreiben, anstatt alles in eine zu kombinieren. Das bedeutet nicht, dass Sie Microservices machen; es ist einfach pragmatische Softwareentwicklung.

Grenzen auf Anwendungsebene sind sehr natürlich, und die meisten Unternehmen tun dies intuitiv, wie z.B. separate Anwendungen für einen Shop, ein PIM und ein Auth-System.

Microservices vs. richtig strukturierte Anwendungen

Ein richtig strukturierter Monolith ist in den meisten Fällen eine sehr tragfähige Alternative. Verwenden Sie so wenige zusätzliche Systeme wie möglich, um die Dinge schnell, einfach und klar zu halten (z.B. PostgreSQL als Dokumentenspeicher, RDBMS-Schicht und Suchanwendung). Erstellen Sie eine 12-Factor App für einfaches Deployment und nutzen Sie Systeme, die das Deployment erleichtern (Beanstalk, Blue-Green Deployments, Zero Downtime).

Wichtig: Sie werden dafür bezahlt, Ihren Kunden Mehrwert zu liefern, nicht dafür, eine benutzerdefinierte Schicht zu implementieren, die Zero-Downtime-Deployments auf EC2-Servern durchführen kann und jeden zweiten Tag ausfällt.

Empfehlungen

• Beginnen Sie immer mit einem richtig strukturierten Monolithen. Das reduziert Risiko und Aufwand.
• Verwenden Sie Microservices nur, wenn Sie wirklich gute Gründe dafür haben.

Wenn Sie diese Empfehlungen beherzigen, können Sie die Fallstricke von Microservices vermeiden und sich darauf konzentrieren, echten Mehrwert für Ihre Kunden zu liefern.

Mehr:

• Wie Amazon Prime von Microservices zu einem Monolithen wechselte und 90% der Kosten einsparte: https://www.reddit.com/r/devops/comments/13cnspx/prime_video_reduces_costs_by_90_by_switching_from/
• 12 Factor App: https://12factor.net/de/
• Der “Majestic Monolith” von DHH: https://signalvnoise.com/svn3/the-majestic-monolith/