© StonePictures/Shutterstock.com
Wenn der Client das API spezifiziert

Kolumne: EnterpriseTales


Wie teste ich eigentlich das Zusammenspiel in meiner Microservices-Landschaft? Wie stelle ich sicher, dass jeweils die richtige Version eines Service auf der richtigen Stage deployt ist? Wie behalte ich die Abhängigkeiten meiner Microservices im Blick? Und wie stelle ich bei der Weiterentwicklung meiner APIs sicher, dass alle Clients weiterhin funktionieren? Wie kann ich sicher sein, dass eine alte Version einer Schnittstelle nicht mehr benötigt wird und deshalb entfernt werden kann? Consumer­-driven Contracts versprechen eine Lösung für alle diese Fragen, kommen aber mit einer erheblichen Komplexität und haben ihrerseits Grenzen.

Das Management der Abhängigkeiten aller Services in einer Microservices-Landschaft stellt eine der größten Herausforderungen dieses Architekturansatzes dar. Fragen danach, welcher Service welche Schnittstelle in welcher Version verwendet, müssen beantwortet werden. Weitgehende Abwärtskompatibilität der Schnittstellen ist deshalb vor allem bei public APIs Pflicht.

Bei den internen APIs, die lediglich genutzt werden, damit die Microservices untereinander kommunizieren können, kann die Sache etwas entspannter angegangen werden: Wenn ein Teil eines API von keinem Client mehr benutzt wird, kann er abgeschaltet werden, egal ob es sich dabei um einen Breaking Change handelt oder nicht. Voraussetzung dafür ist, eine Möglichkeit zu haben, die herausfindet, ob ein (internes) API noch verwendet wird oder nicht. Ein möglicher Lösungsansatz sind Consumer-driven Contracts.

Entfernen alter APIs

Normalerweise ist es so, dass der Anbieter eines API es spezifiziert und dokumentiert, um seinen Clients die Möglichkeit zu bieten, das API auf eine definierte Art zu benutzen. Im Kontext von Consumer-driven Contracts wird das als Provider Contract bezeichnet.

In der Praxis ist es allerdings häufig so, dass es keinen Client gibt, der die gesamte Breite der angebotenen Schnittstelle verwendet. Tatsächlich nutzt jeder Client in der Regel nur einen kleinen Teil einer angebotenen Schnittstelle. Dieser Teil wird als Consumer Contract bezeichnet. Die Summe der Consumer Contracts ist dann das, was der Provider tatsächlich als Schnittstelle zur Verfügung stellen muss. Häufig ist dieser Teil kleiner als der tatsächlich angebotene Provider Contract. Insbesondere, wenn der Provider noch alte Versionen von APIs anbietet, wäre ein Mechanismus wünschenswert, mit dem er feststellen könnte, dass es keinen Client mehr gibt, der diese noch benutzt.

Die Idee hinter Consu...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang