© Excellent backgrounds/Shutterstock.com
Alte Prinzipien mit neuen Services

Solide Microservices


Microservices bieten Vorteile bei der Abgrenzung von Funktionalität und Verteilung in einem Netzwerk. Auch in der Vergangenheit existierten schon Prinzipien, die ähnliche Ziele verfolgt haben. Eines dieser Prinzipien ist SOLID. Die Frage lautet also: Wie solide sind Microservices?

Video: Die dunkle Seite der Microservices

Es ist nicht das erste Mal, dass Softwareentwickler vor dem Problem stehen, dass ein System zu groß geworden ist und ein Entwickler es in seiner ganzen Komplexität nicht mehr verstehen kann. Schon im Rahmen der objektorientierten Programmierung haben sich Verfahren und Prinzipien entwickelt, die hierbei helfen sollen. Die Komplexität soll in handhabbare Objekte, sprich Klassen, aufgeteilt werden. Für das Klassendesign haben sich im Laufe der Jahre einige gute Regeln herausgebildet. Eine der bekanntesten Sammlungen nennt sich SOLID. Diese Abkürzung umfasst die folgenden fünf Prinzipien, aus deren Anfangsbuchstaben sich der Name des Prinzips ergibt:

  • Single Responsibility Principle (SRP): Eine Klasse soll nur eine Aufgabe erfüllen.

  • Open Close Principle (OCP): Eine Klasse soll offen für Erweiterungen sein, aber geschlossen für Modifikationen.

  • Liskov Substition Principle (LSP): Für einen Verwender soll eine Instanz einer Superklasse immer durch seine Subklassen ersetzbar sein.

  • Interface Segregation Principle (ISP): Ein Verwender soll eine Schnittstelle angeboten bekommen, die nur seiner Aufgabe entspricht.

  • Dependency Inversion Principle (DIP): Die Abhängigkeit soll nur von höheren Modulen zu niedrigeren gehen.

Da in den Umgang mit diesen Prinzipien bereits etliche Jahre Erfahrung eingeflossen sind, ist es eine interessante Übung herauszufinden, wie diese Prinzipien beim Design von Microservices helfen können.

Single Responsibility Principle: Eine Aufgabe erfüllen

Das Single-Responsibility-Prinzip besagt, dass eine Klasse nur eine Verantwortung haben darf. Eine Klasse soll eine und nur eine Aufgabe übernehmen. In der Softwareentwicklung haben sich gute Faustregeln entwickelt, um zu prüfen, ob dieses Prinzip wirklich eingehalten wird. Die bekannteste Regel lautet, dass alle Klassen, die mit Manager oder Handler bezeichnet werden, schon dubios sind. Wenn der Entwickler keinen besseren Oberbegriff findet als das Managen von Aufgaben, dann deutet das normalerweise auf eine Klasse hin, die viele Aufgaben zu erledigen hat. Die Konsequenz wiederum ist, dass diese Klasse im Herz des Systems arbeitet und dort auch viel zu tun hat. Das wäre im Prinzip nicht schlecht. Aber im Rahmen der Weiterentwicklung sind solche zentralen Klassen immer schwierig, weil sie den Charakter eines Magneten haben: Jede Änderung am System bedarf einer Änderung in einer beliebigen Klasse und dem Manager oder Handler.

fildebrandt_mircoservices_1.tif_fmt1.jpgAbb. 1: Ein Microservice für eine Verantwortlichkeit

Auf Microservices angewendet sollte der Entwickler überlegen, ob der Service, den er gerade entwickelt, genau dieselben Charakteristiken besitzt. Ist er auch eine zentrale Komponente, die magisch alle Änderungen an sich zieht? Dann sollte man das Design der Microservices hinterfragen, ob man einen solchen Service nicht noch weiter aufteilen kann, um einen Flaschenhals im System zu verhindern.

Microservices sind eigentlich laut Definition so zu bauen, dass sie eine Aufgabe im System vollkommen entkoppelt lösen. Man könnte sagen, dass das Single Responsibility Principle das entscheidende Merkmal eines Microservice ist. Dennoch ist dieses Prinzip ein gutes Beispiel dafür, dass sich die Prinzipien von SOLID gut auf Microservices anwenden lassen bzw., dass ein Entwickler sie tunlichst anwenden sollte, um zu einem guten Systemdesign zu gelangen.

Open Closed Principle: Offen und geschlossen gleichzeitig

Das Open Closed Principle empfiehlt, dass ein Klasse offen für Erweiterungen und geschlossen für Modifikationen sein soll. Die Geschlossenheit für Modifikationen beruht darauf, dass eine spätere Änderung das Verhalten einer bestehenden Implementierung nicht verändern soll. Vor allen Dingen nicht, wenn die ursprüngliche Implementierung es nicht gut kapseln kann. Modifikationen widersprechen an sich einer guten Kapselung. Offenheit bezieht sich darauf, dass man eine Klasse an zukünftige Anforderungen anpassen kann. Diese Anpassungen sollten allerdings vorgedacht sein und nicht beliebig durch Modifikationen des bestehenden Sourcecodes passieren.

Microservices sind gut geschützt vor Modifikationen. Denn über das interne Verhalten einer Implementierung wird nichts nach außen propagiert. Bei Microservices wird das Argument, dass die Implementierungstechnologie für einen Microservice frei wählbar ist, oft gleich als Erstes aufgeführt. Denn die Implementierungstechnologie ist durch Remoteschnittstellen verborgen. Heutzutage werden meistens REST-Schnittstellen verwendet, sodass der Microservice nur per HTTP erreichbar ist. Eine Modifikation ist dadurch ausgeschlossen.

fildebrandt_microservices_2.tif_fmt1.jpgAbb. 2: Erweiterungen von Microservices: die Remote-Schnittstelle verwenden

Die Offenheit gegenüber Erweiterungen ist dagegen ein wenig schwieriger. Denn ein Microservice an sich ist nicht erweiterbar, er e...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang