Über das Management von Microservices Was für ein modernes API-Management nötig ist

Anbieter zum Thema

Dell GmbH

VMware Global Inc Zweigndl. Deutschland

DataCore Software GmbH

F5 Networks GmbH

Wenn Unternehmen ihre Anwendungen auf Microservice-basierte Architekturen migrieren, eignen sich dafür herkömmliche API-Management-Lösungen nicht. Denn diese entstanden lange bevor Public Clouds, DevOps und CI/CD-Tools eingeführt wurden.

Nach aktuellen Studien müssen Aufrufe von Application Programming Interfaces (APIs) innerhalb von 30 Millisekunden verarbeitet werden, um die von Nutzern geforderte Echtzeitinteraktion mit Anwendungen zu bieten. Herkömmliche Architekturen erlauben dies nicht, da sie API-Aufrufe auf ihrem Weg zur Datenebene und zu den API-Endpunkten in der Regel durch die Steuerungsebene leiten. Dies führt zu zusätzlicher Latenzzeit.

Sie eignen sich auch nicht für moderne verteilte Anwendungen aus Microservices, die sich an mehreren Standorten oder in Cloud-Umgebungen befinden. Denn der gesamte API-Verkehr muss authentifiziert und über das Netzwerk geroutet werden, um die eng gekoppelte Kontroll- und Datenebene zu passieren.

Die Entwicklung der Software-Integration

Um zu verstehen, warum diese Hindernisse entstanden sind, ist ein Blick in die Vergangenheit nötig. In den frühen 2000er Jahren erhöhte sich der Bedarf für eine Integrationsschicht, um Frontend-Dienste mit Backend-Technologien wie Mainframes, Message Queues und Datenspeichern zu verbinden. Middleware-Tools, die als Enterprise Service Bus (ESB) bezeichnet wurden, boten dafür immer mehr Funktionen. Zur Vernetzung und Integration von internen Geschäftsprozessen entwickelten ESB-Anbieter APIs, die in der Regel SOAP-Nachrichten (SOAP = Service Oriented Architecture Protocol) zum Datenaustausch und XML-formatierte (XML = Extensible Markup Language ) Daten verwendeten.

Mit zunehmendem Internet-Verkehr und modernen Mobilgeräten benötigten Fachabteilungen agilere Wege, um neue Produkte und Dienstleistungen auf den Markt zu bringen. Dies führte zur Einführung moderner Web-Frameworks sowie zu einfacheren REST-APIs und JSON-formatierten Daten (REST = REpresentational State Transfer, JSAON = JavaScript Object Notation).

Im Jahr 2019 stellte Akamai fest, dass 83 Prozent des Web-Verkehrs aus API-Aufrufen bestehen. Als der Enterprise Service Bus an Bedeutung verlor, versuchten die ESB-Anbieter, ihren Marktanteil durch das Bereitstellen von API-Funktionalität zu halten. Dies führte zwar zu schnellen Erfolgen, doch der Trend bewegte sich bereits rasch in Richtung Microservices.

Probleme durch herkömmliches API-Management

Das bedeutet: Viele der heutigen API-Management-Frameworks begannen als ESBs. Sie wurden entwickelt, lange bevor die Public Cloud zum Mainstream wurde oder Microservices, DevOps-Methoden oder CI/CD-Prozesse zum Einsatz kamen. So haben sie Schwierigkeiten, die aktuell geforderten Geschwindigkeiten bei API-Aufrufen zu erfüllen.

Denn diese leiten sie meist über die Steuerungsebene zu den API-Endpunkten. Dies erhöht die Latenzzeit, da die eng gekoppelten Steuer- und Datenebenen jederzeit verbunden sein müssen, damit API-Aufrufe verarbeitet werden können. Darüber hinaus besteht die Steuerungsebene oft aus vielen beweglichen Teilen. Dies erfordert Module von Drittanbietern, Skripte und eine Datenbank zur Verwaltung, Überwachung und Analyse der APIs. Dies kann die Fehlerbehebung aufgrund mangelnder Transparenz erschweren.

Herkömmliche API-Frameworks sind auch nicht für moderne verteilte Anwendungen geeignet. Diese bestehen aus Microservices, die sich an mehreren physischen Standorten oder in Clouds befinden. Wenn ein Unternehmen zum Beispiel Workloads in Public- und Private-Cloud-Umgebungen ausführt, die ein SaaS-basiertes oder selbstverwaltetes traditionelles API-Management-Framework nutzen, erreicht es kaum niedrige Latenzzeiten.

Dies liegt daran, dass der gesamte API-Verkehr authentifiziert und über das Netzwerk geleitet werden muss, um durch die eng gekoppelte Kontroll- und Datenebene zu gelangen. Dieser Engpass wird auch als „Posauneneffekt“ bezeichnet. Er entsteht, wenn die Netzwerkarchitektur eine verteilte Organisation dazu zwingt, einen einzigen sicheren Ausgangspunkt zum Internet zu nutzen.

Herausforderungen bei SaaS

Eine weitere Herausforderung für viele Unternehmen stellen SaaS-basierte Angebote dar. Wer eine Sicherheitsrichtlinie für das Netzwerk nach dem Prinzip Zero Trust verfolgt, besitzt wahrscheinlich eine Firewall zwischen dem API-Management-Framework und dem Backend-Service, der die API bereitstellt. Jede Änderung an diesem Backend-Service kann eine Anpassung der Firewall erfordern. Da diese in der Regel nicht vom Entwicklungsteam durchgeführt werden darf, kann das zu erheblichem Aufwand und Frustration für agile DevOps-Teams führen.

Zudem ist das Routing interner API-Aufrufe durch eine Cloud außerhalb des Unternehmensnetzwerks ineffizient und kann sich negativ auf die API-Performance sowie auf die Security der gesamten Organisation auswirken. Eine weitere Folge der zunehmenden Public-Cloud-Nutzung ist die Einführung von Infrastructure as Code. Dezentralisiertes Management, bei dem etwa ein Fachbereich oder ein DevOps-Team (DevOps = Development Operations) seine eigene Infrastruktur betreiben und verwalten kann, ist problematisch für herkömmliche API-Management-Frameworks.

Denn diese sind darauf ausgelegt, dass sie von einem zentralen Team betrieben und verwaltet werden. DevOps-Teams können dann nicht einmal ihre eigenen Gateways für Test-, Entwicklungs- und Sandbox-Umgebungen im Rahmen ihrer CI/CD-Pipeline einsetzen. Dies macht es fast unmöglich, Technologien wie Docker zu nutzen.

Herkömmliche API-Management-Frameworks führen auch häufig zu hohen Kosten. Zwar gibt es eine Fülle von verschiedenen Kostenmodellen für APIs, einschließlich pro Administrator, pro API, pro Gateway oder Kombinationen davon – mit ihren jeweiligen Vor- und Nachteilen. Doch eines haben sie gemeinsam: Man kann nur sehr schwer vorhersagen, wie hoch die Ausgaben im kommenden Jahr sein werden. Bei SaaS-basierten Frameworks, die pro API-Aufruf abgerechnet werden, müssen Kunden sogar teilweise für fehlerhafte Aufrufe oder DDoS-Angriffe zahlen.

Zeitgemäßes API-Management

Entsprechend benötigen Unternehmen, die ihre Anwendungen modernisieren, auch eine neue Art von API-Management-Tools. Diese sollten folgende Funktionen aufweisen:

• Eine entkoppelte Steuerungs- und Datenebene, die keine ständige Konnektivität erfordert. Dadurch können Kunden die Datenebene (API-Gateways) näher an ihren Anwendungen betreiben. Das reduziert die Latenzzeiten erheblich, da API-Aufrufe nicht mehr über die Steuerungsebene geleitet werden. Dies ist von entscheidender Bedeutung in containerisierten Umgebungen, in denen eine große Menge an Ost-West-Verkehr (Interservice-Verkehr) entsteht.

• Eine für die Multicloud-konzipierte Architektur. Bei einer entkoppelten Architektur können Unternehmen die Datenebene neben jeder Anwendung betreiben, da der API-Verkehr sie nicht durchläuft. Dies vermeidet auch die Notwendigkeit einer Firewall zwischen dem SaaS-basierten API-Management-Framework und den Anwendungen.

• Bereitstellung und Verwaltung von APIs als Self-Service. Mit einer entkoppelten Architektur kann jeder Fachbereich und jedes DevOps-Team eigene API-Gateways bereitstellen und verwalten. Gleichzeitig behalten NetOps- und SecOps-Teams (NetOps = Network Operations, SecOps = Security Operations) weiterhin die Kontrolle über die Sicherheitsrichtlinien auf der Steuerungsebene. Damit können Unternehmen agile Entwicklungsmethoden auf einfachere Weise einführen.

* Steffan Henke ist Technical Solutions Architect bei Nginx.

(ID:47035805)