Mastering Kubernetes 2023, Juli 2023, Sonja Wegner
Gute APIs sind das Herzstück erfolgreicher digitaler Produkte und Cloud-nativer Anwendungen. Doch schlecht verwaltete APIs werden schnell zum Albtraum. Damit es kein böses Erwachen gibt, setzen wir auf API Gateways: Diese sind etabliert und bekannt und helfen uns bei der Verwaltung der APIs. Sie regeln unter anderem Traffic Management, Rollout-Szenarien, Versionierung, Zugriffskontrolle und Diagnostizierbarkeit.
In diesem Vortrag werden wir das Cloud-native API-Gateway-Ökosystem näher betrachten: Gloo, KrakenD, Kong, Envoy et al. Aber welches davon ist das Richtige für den Einsatz im nächsten Projekt? Lasst es uns herausfinden!
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
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