© Excellent backgrounds/Shutterstock.com
Java Magazin
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.

Arne Limburg


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 APIsIn 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 Consumer-driven Contracts ist es, genau das zu erreichen, indem die Clients kontinuierlich ihre Consumer Contracts an den Provider übermitteln. Der kann sie dann verwenden, um seine angebotenen Schnittstellen zu testen. Alle Schnittstellen, zu denen es keinen aktuellen Consumer Contract gibt, können entfernt werden.Aber auch wenn es darum geht, eine neue Schnittstelle zu definieren oder eine Schnittstellenerweiterung vorzunehmen, erweisen sich Consumer-driven Contracts als sinnvoll.AnforderungspraxisMit Consumer-driven Contracts ist eine solche Möglichkeit geschaffen. Der Consumer, der die neue Schnittstelle benötigt, erstellt einfach einen Consumer Contract und übermittelt ihn an den Provider. Bei richtigem Einsatz bietet diese Variante die Chance, die Qualität des Austauschs zwischen den beiden Teams erheblich zu verbessern. Jede Absprache wird in einem Consumer Contract formal und sehr detail...

Java Magazin
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.

Arne Limburg


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 APIsIn 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 Consumer-driven Contracts ist es, genau das zu erreichen, indem die Clients kontinuierlich ihre Consumer Contracts an den Provider übermitteln. Der kann sie dann verwenden, um seine angebotenen Schnittstellen zu testen. Alle Schnittstellen, zu denen es keinen aktuellen Consumer Contract gibt, können entfernt werden.Aber auch wenn es darum geht, eine neue Schnittstelle zu definieren oder eine Schnittstellenerweiterung vorzunehmen, erweisen sich Consumer-driven Contracts als sinnvoll.AnforderungspraxisMit Consumer-driven Contracts ist eine solche Möglichkeit geschaffen. Der Consumer, der die neue Schnittstelle benötigt, erstellt einfach einen Consumer Contract und übermittelt ihn an den Provider. Bei richtigem Einsatz bietet diese Variante die Chance, die Qualität des Austauschs zwischen den beiden Teams erheblich zu verbessern. Jede Absprache wird in einem Consumer Contract formal und sehr detail...

Neugierig geworden?


   
Loading...

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