Das Dokument behandelt die Bedeutung von API-Gateways in cloud-nativen Architekturen und ihren Einfluss auf das Management von APIs. Es werden Vor- und Nachteile von API-Gateways sowie verschiedene Implementierungen und Designmuster vorgestellt, um deren Nutzen zu maximieren und typische Fallstricke zu vermeiden. Zudem werden Kriterien für die Bewertung und Auswahl von API-Gateway-Lösungen erläutert.

1. qaware.de
Per Anhalter zu Cloud-nativen API
Gateways
Sonja Wegner, QAware GmbH

2. Sonja Wegner
Lead Software Architect @ QAware GmbH

3. Monolithic
Vintage System
Users
system.example.com

4. Users
Monolithic
Vintage System
A Cluster
A Namespace
Service A
system.example.com
service-a.default.example.com
Route

5. Monolithic
Vintage System
A Cluster
A Namespace
Service A
system.example.com
service-a.default.example.com
Route
Service B
Route
service-b…
Users

6. Monolithic
Vintage System
A Cluster
A Namespace
Service A
system.example.com
service-a.default.example.com
Route
Service B
Route
service-b…
Service C
Route
service-c…
Users

7. Monolithic
Vintage System
A Cluster
A Namespace
Service A’
system.example.com
service-a.default.example.com
Route
Service B
Route
service-b…
Service C'
Route
service-c…
Users
3rd Party Apps

8. Monolithic
Vintage System
A Cluster
A Namespace
Service A’
system.example.com
service-a.default.example.com
Route
Service B
Route
service-b…
Service C'
Route
service-c…
B Namespace
Service X
Service Y
Service Z’
Unreliable
Legacy
Systems
SOAP
gRPC
3rd Party Apps Users

9. Monolithic
Vintage System
A Cluster
A Namespace
Service A’
system.example.com
service-a.default.example.com
Route
Service B
Route
service-b…
Service C'
Route
service-c…
B Namespace
Service X
Service Y
Service Z’
SOAP
gRPC
Route
Internal
Systems
3rd Party Apps Users
Unreliable
Legacy
Systems

10. Höchste Zeit für API Maintenance!
APIs sind das Herzstück erfolgreicher,
digitaler Produkte.
Das richtige Management der APIs
von Beginn an ist essentiell, um den
Big Ball of Mud zu vermeiden.
https://thenewstack.io/history-service-mesh/

11. Monolithic
Vintage System
A Cluster
A Namespace
Service A
Service B
Service C
B Namespace
Service X
Service Y
Service Z
Unreliable
Legacy
Systems
SOAP
API
Gateway
BFF
Internal
Systems
API
Gateway
API
Proxy
Users
3rd Party Apps

12. Mit dem Einsatz von API Gateways wenden wir etablierte
Design Patterns auf Microservice Architekturen an:
■ Facade
– Komplexe Aufrufwege, Interna über die Service Architektur etc. werden hinter dem
Gateway versteckt
– Umbenennungen, Refactorings, … sind problemlos möglich, weil Abnehmer nur mit dem
Gateway als Facade interagieren
■ DRY
– Querschnittliche Funktionalität wird direkt im Gateway abgebildet
■ Decoupling
– Reine Fachlogik in den Microservices
– BFF, Routing, Auth, … im Gateway

13. Querschnittsfunktionalität - im API Gateway?
■ Traffic Management: Path, Header, Host based Routing, Path Rewrite
■ Rollout and Deployment: A/B Deployment, Canary Release, et.al.
■ QoS and Resiliency: Circuit Breaker, Retry, Timeouts, Rate Limiting
■ Security: AAA, Terminate TLS, Support for JWT and JWKS, Open ID, …
■ Protocol Translation: XML to JSON, gRPC to JSON, …
■ Transformation: Fan Out / Collect, B4F, Versioning, GraphQL, …
■ Observability: Logging Integration, Monitoring, Distributed Tracing

14. Vor- und Nachteile von API Gateways
Möglicher Nutzen und Vorteile
■ Abstraktion der internen
Anwendungsarchitektur, ermöglicht lose
Kopplung
■ Vereinfachter Client Code, konsistentes
Interface für Abnehmer
■ Einfaches Rollout und Deployment,
Versionierung, …
■ BFFs reduzieren die Anzahl benötigter
Client-Server Calls
■ Positiver Performance Impact durch Caching,
einfachere Aufrufwege, …
■ Monitoring und Troubleshooting
■ Reduzierte Angriffsfläche
Mögliche Nachteile
■ Weiterer hoch-verfügbarer
Infrastruktur-Baustein, Single Point of Failure
■ Wird schnell zum DevOps-Flaschenhals im Fall
vom zentralem Betrieb
■ Ggf. redundant: falls Load Balancing,
Observability, Rate Limiting etc. schon von
anderen, bereits bestehenden Bausteinen
übernommen werden
■ Business-Logik im API Gateway führt
versehentlich zu einem ESB
■ Schlechte Performance bei falscher
Konfiguration

15. API Gateway vs. Service Mesh
■ API Gateways für “Nord-Süd”
Kommunikation /
Kommunikation mit der
Außenwelt
■ Service Meshes für “Ost-West”
Kommunikation / interne
Kommunikation zwischen
Services

16. https://landscape.cncf.io/

17. https://landscape.cncf.io/

18. Vergleichs- und Bewertungskritierien
■ Maturity: Gute und aktive Community, keine Issues, häufige Releases
■ License and Cost: Open Source oder Commercial
■ Supported Features: Traffic Management, Deployment, Security, Translation, Transformation,
QoS, Resiliency, …
■ DevOps Friendly: Einfaches Setup und Betreibbarkeit, Verfügbarkeit als Managed Service,
CI/CD und GitOps Support, Documentation, Erweiterbarkeit, Integrierbarkeit in den DevOps
Workflow, einfache Konfigurierbarkeit, …
■ Performance: Kleiner Overhead, hoher Durchsatz, Skalierbarkeit, Verfügbarkeit, Features zur
Performanceverbesserung

19. API Gateway = API Gateway?
Der Versuch einer Kategorisierung:
A.
API Management
Solutions /
Platforms
B.
Build your own
API Gateway
C.
Service Proxies
D.
Cloud Native API
Gateways

20. A. API Management Solutions / Platforms
■ Beispiele: Apigee, Amazon API Gateway, Mulesoft UAPIM, Kong Enterprise, …
■ Lizenzen und Kosten: Häufig kostenpflichtig, manchmal aber auch mit Open Source Varianten
mit eingeschränktem Feature Umfang
■ Besonderheiten: Features wie API Kataloge, Developer Portale, API Key Management,
Lösungen oder Integrationen für Bezahlung, …
■ DevOps: Üblicherweise zentral deployed und betrieben für alle Applikationen und Produkte im
Unternehmen

21. B. Build your own API Gateway
■ Beispiele: Spring Cloud Gateway, Netflix Zuul, Node, Apache Camel, … und zahlreiche weitere
Frameworks
■ Lizenzen und Kosten: Oft Open Source, muss individuell bewertet werden
■ Besonderheiten: Extrem flexibel, da sehr einfache Integration von eigenem Code…
■ DevOps: Liegt komplett in der Hand des Teams. Entwicklung, Wartung, Betrieb müssen
individuell erbracht werden, verursacht Aufwand und birgt Risiken.

22. C. Service Proxies
■ Beispiele: Nginx, Envoy, HA Proxy, Traefik, …
■ Lizenzen und Kosten: Oft Open Source, muss individuell bewertet werden
■ Besonderheiten: Leichtgewichtig, oft einfach in der Konfiguration und Nutzung.
■ DevOps: Unterstützte Funktionen unterscheiden sich teilweise signifikant

23. D. Cloud Native API Gateways
■ Beispiele: KrakenD, Gloo, Kusk, Emissary Ingress, APISIX, …
■ Lizenzen und Kosten: Sehr unterschiedlich, sowohl Open Source als auch kommerzielle
Varianten
■ Besonderheiten: Basieren häufig auf Envoy mit zusätzlichen Erweiterungen und Plugins
■ DevOps: bieten tiefe Integration in K8s und Platformen der Cloud Provider. DevOps Workflow
ist teilweise sehr unterschiedlich. Erweiterbarkeit und dafür unterstützte Programmiersprachen
sowie unterstützte Features unterscheiden sich

24. API Gateway Composition
The Enterprise
API
Management
Solution
On-Premise Servers
Service
Proxy
Some Public Cloud
Managed K8s
Cloud
Gateway
Gateway
Shared PaaS
Namespace
Custom
Gateway
Service Proxy
Legacy Backend

25. Demo

26. Conclusion

27. qaware.de
QAware GmbH
Aschauer Straße 32
81549 München
Tel. +49 89 232315-0
info@qaware.de
twitter.com/qaware
linkedin.com/company/qaware-gmbh
xing.com/companies/qawaregmbh
slideshare.net/qaware
github.com/qaware