In einer Welt voller Microservices begegnet man zwei Buzzwords immer öfter – “API Management” und “Service Mesh”. Wir haben uns die Frage gestellt, bei welchen Herausforderungen die beiden Ansätze helfen und ob es ein “Entweder-oder” ist? Hierzu haben wir beides unter die Lupe genommen, um zu schauen, was wirklich dahintersteckt. Unsere Meinung: Ein “und” kann durchaus sinnvoll sein. Aber lasst uns gemeinsam mal draufschauen.
Service Mesh zur Verwaltung eines Service-Netzwerks
Softwareentwicklung in agilen Teams funktioniert super. Durch Unabhängigkeit erreichen wir Flexibilität und Geschwindigkeit und können so neue Funktionen schnell bereitstellen. Dies erfüllt zunächst die wichtigsten Kriterien für erfolgreiche Entwicklerteams. Grundvoraussetzung hierfür ist, dass wir Fachlichkeit in überschaubare Einheiten zerteilen und in Form von kleinen, isolierten Systemen (sog. Microservices oder Self-contained Systems) bereitstellen. Blickt man auf die gesamte IT-Landschaft größerer Unternehmen, findet man heute sehr häufig sehr viele verteilte Microservices, die von vielen agilen Teams verantwortet werden.
Dabei haben alle verantwortlichen Entwicklerteams ähnliche Herausforderungen. Neben der Umsetzung der eigentlichen geschäftlichen Anforderung bringen verteilte Architekturen einen immer größer werdenden Teil von betrieblichen und nicht-funktionalen Anforderungen mit. Dabei müssen sich die Teams unter anderem mit diesen Fragestellungen auseinandersetzen:
- Was kann ich tun bei schlechter Netzwerk-Stabilität?
- Wie kann ich sicher über das Netzwerk kommunizieren?
- Wie erkenne ich Fehlerursachen in der verteilten Architektur schnell?
- Wie kann ich häufig neue Releases deployen, ohne andere Microservices dabei negativ zu beeinflussen?
Die Beantwortung dieser Fragen ist häufig von individuellen Lösungen geprägt, welche Teil der Logik der Microservices sind. An dieser Stelle setzen Service Meshes an. Sie sorgen dafür, dass sich Entwicklerteams wieder mehr auf die eigentlichen fachlichen Anforderungen konzentrieren können. Dies tun sie, indem sie die Kommunikation zwischen den verschiedenen Microservices verwalten und überwachen.
Ein Proxy wird als sogenanntes Sidecar mit jedem Microservice deployt. Alle eingehende und ausgehende Netzwerk-Kommunikation wird dann über den Proxy durchgeführt. Mit jedem Aufruf können nun regelbasierte Zusatzfunktionen vom Proxy erfüllt werden. Es können also unabhängig von der eigentlichen Anwendung zur Laufzeit neue Regeln auf einzelne Services oder auf das gesamte Service-Netzwerk angewendet werden.
Ein Service Mesh kann für viele Funktionen eingesetzt werden
Neben zahlreichen Monitoring- und Tracing-Funktionen, welche für Transparenz in einem verteilten System sorgen und damit auch die Fehleranalyse erleichtern, bieten Service Meshes noch weitere nützliche Funktionen:
- Security: Mutual SSL/TLS ermöglicht die Verschlüsselung sowie Authentifizierung und Autorisierung der Netzwerk-Zugriffe. Die notwendigen Zertifikate werden dabei regelmäßig automatisiert ausgetauscht. So können ganze Netzwerke über einen sehr einfachen Mechanismus abgesichert werden.
- Routing: Canary Releases ermöglichen neue Microservice-Versionen parallel zu deployen und über Routing-Regeln den Traffic zwischen den beiden Version aufzusplitten, so dass nur ein definierter Teil der Anfragen auf die neue Version geht. Damit kann das Risiko bei der Einführung von neuen Versionen reduziert werden, indem nur ein Teil der Benutzer/des Systems von möglichen Fehlern betroffen ist.
- Resilience: Über Circuit Breaker, Retry und Timeouts kann auf Fehlersituationen definiert und regelbasiert in Services reagiert werden, damit auch bei Ausfällen und Fehlern anderer Services der individuelle Service funktionsfähig bleibt. Beispielsweise kann bei mehrfachen fehlerhaften Aufrufen eines Systems eine Sicherung (Circuit Breaker) dafür sorgen, dass keine weiteren Aufrufe durchgeführt werden und stattdessen ein Fallback greift. Sollte ein System gar nicht antworten, können Timeouts für eine definierte Fehlerreaktion und nicht-blockierende Prozesse sorgen.
- Fault Injection: Mit dieser Funktion kann die Fehlerresistenz (und damit die getroffenen Resilience-Maßnahmen) eines Microservices bzw. ganzer Microservice-Systeme getestet werden. Beispielsweise kann über Delays die Antwortzeit von Services verzögert werden, um ein hohes Auslastungsszenario zu simulieren. Aborts können verwendet werden, um komplette Ausfälle zu simulieren.
APIs gibt’s schon lange – was ist nun der Unterschied zu einem Service?
APIs sind in den letzten 10 Jahren immer populärer geworden. Heute sehen wir den Einsatz von APIs in sehr vielen Bereichen unseres Lebens, wie z.B. in Connected Homes und Mobile Applications. Darüber hinaus sind sie Kernbestandteil der digitalen Transformation für viele Unternehmen, um Zugang zu den eigenen Daten und Geschäftsfunktionen zu ermöglichen. Generell werden sie also (wie Services auch) dazu genutzt, die Integration bzw. den Zugang zu bestimmten Daten und Funktionen zu ermöglichen.
Wichtig hierbei ist: APIs haben im Gegensatz zu Services immer eine definierte fachliche Bedeutung und sind über den individuellen Systemkontext hinaus von Relevanz. Sie kapseln eine in sich geschlossene, sinnvolle fachliche Logik, welche potenziell für weitere Aufrufer relevant sein könnte. Daher sprechen wir häufig von “API-Produkt”, um den Produktcharakter von APIs zu unterstreichen. Produkte könnten auch auf einem Marktplatz für andere Interessenten angeboten werden. Dies ist bei Services nicht immer der Fall. Häufig handelt es sich dabei um Punkt-zu-Punkt-Verbindungen bzw. teilweise auch technische Services, die nur im Kontext einer größeren Microservice-Applikation einen Sinn ergeben.
Grundsätzlich könnte also in einem Service Mesh jeder Service auch eine API für die übergreifende Verwendung anbieten. In der nachfolgenden Abbildung ist dies für den Product Service der Fall. Produkte könnten ja nicht nur für die Online-Shop-Anwendung relevant sein, sondern z.B. auch für Vergleichsportale, welche von außen darauf zugreifen wollen.
Wozu brauche ich API Management?
Stellen wir uns die API als Produkt vor: Was wäre grundsätzlich notwendig, um dieses Produkt zu vermarkten bzw. zu verkaufen? Das Produkt müsste:
- über einen Katalog oder Marktplatz schnell auffindbar sein,
- übersichtlich und verständlich dokumentiert sein,
- klare Verkaufsbedingungen bzw. Preisinformationen enthalten sowie
- nach der Kaufabwicklung dem Käufer zugänglich gemacht werden.
Für die Weiterentwicklung des Produktes ist es auch wichtig zu verstehen, wie und von welchen Nutzergruppen das Produkt gekauft und verwendet wird.
Exakt diese Funktionen bieten API-Management-Plattformen an. APIs werden also zentral verwaltet, um sie:
- zur Nutzung für Consumer anbieten und beschreiben zu können sowie
- die Nutzung/den Kauf in Form einer Subscription im Self-Service-Ansatz für Entwickler zu ermöglichen,
- den Zugriff von berechtigten Konsumenten zu kontrollieren, zu protokollieren sowie zu analysieren.
Service Mesh oder API Management oder beides?
Der wesentliche Unterschied zwischen den beiden Ansätzen ist, dass Service Meshes eher zur technischen Verwaltung des Netzwerk-Traffics zwischen Services verwendet werden, während sich API Management eher auf fachliche Aspekte zur Verwaltung von APIs und deren Konsumenten bezieht.
Beide Ansätze können sich aber auch sehr gut ergänzen, da es einige Gemeinsamkeiten gibt:
- Beide Lösungen basieren auf dem einfachen Konzept, Proxies in die Netzwerk-Kommunikation zwischenzuschalten.
- Beide Lösungen sind in der Lage, Security und Zugriffskontrollen abzubilden.
Es ist also sinnvoll, das Konzept von Service Meshes mit API-Management-Plattformen zu integrieren. Dies ermöglicht es, das volle Funktionsspektrum abzudecken, falls dies erforderlich sein sollte. API Management Policies, wie bspw. Authentifizierung (z.B. durch API-Key-Validierung), Rate Limiting usw., können so durch die API-Management-Plattform deployt und verwaltet werden, ohne einen zusätzlichen Proxy verwalten zu müssen. Dies wird bereits von zahlreichen API-Management-Plattformanbietern unterstützt, wie z.B. von Apigee und WSO2, um nur einige zu nennen.
Nachfolgend sind die wesentlichen Unterschiede nochmals detailliert aufgeführt:
