CloudBuilders 2022: "The Past, Present, and Future of Cloud Native API Gateways"
0 likes66 views
The document discusses the evolution of API gateways driven by changes in application architecture and technology. It describes how API gateways evolved from hardware load balancers to software load balancers to application delivery controllers to first-generation API management platforms as applications moved to the cloud and adopted microservices. Managing APIs and microservices at the edge with Kubernetes poses new challenges around scaling edge management and supporting diverse requirements. The document outlines three strategies for managing APIs at the edge with Kubernetes and concludes that choosing an API gateway intentionally is important when adopting cloud-native technologies and platforms.
CloudBuilders 2022: "The Past, Present, and Future of Cloud Native API Gateways"
- 1. The Past, Present, and Future of Cloud Native API Gateways Daniel Bryant Head of DevRel @ Ambassador Labs
- 2. tl;dr • API gateways have undergone a series of evolutions, driven by architecture and technology • Adopting microservices, Kubernetes, and cloud also changes the workflow • Choose your Kubernetes API gateway (and platform) intentionally 2
- 4. 4 Edge: The boundary between your data center and your user(s)
- 5. 5 Thesis: The evolution of the edge has been driven by application architecture and technology
- 6. 6 ~1995
- 7. Application Architecture in the ‘90s 7
- 8. Hardware Load Balancer 8 User Systems administrators Purpose High availability / scalability Key Features Load balancing (round robin, sticky sessions) Health checks
- 9. 9 ~2000
- 10. Similar application architecture (some SOA?) 10
- 11. 11 2002 2001
- 12. So ft ware Load Balancer 12 User Systems administrators (“pre DevOps”) Purpose High availability / scalability Key Features Load balancing Health checks Observability
- 13. 13 ~2005
- 14. 14
- 15. 15 Ecommerce 0 75 150 225 300 2000 2005 2010 2015 2019 Amazon Revenue, Billions
- 16. 16
- 17. The Application Delivery Controller (ADC) 17
- 18. Application Delivery Controllers (ADCs) 18 User Systems administrators Purpose High availability and application acceleration Key Features SSL o ff load, caching, compression + load balancing
- 19. 19 ~2010
- 20. The proliferation of APIs 20 2005: API launched 2008 2009
- 21. API Gateway (1st Gen) 21 User Systems administrators & API developers Purpose Expose business APIs to broader ecosystem (“API management”) Key Features L7 routing (e.g., throttling), Publishing, Dev Portal, Analytics, Monetization
- 22. 22 ~2015
- 23. 23
- 24. Mini-services 24
- 25. API Gateway (2nd Generation) 25
- 26. API Gateway (2nd Generation) 26 User Systems administrators & API developers Purpose Centralize cross-cutting app concerns Key Features Authentication, rate limiting, monitoring + routing
- 28. Cloud-Native Microservices 28 • Modularisation (“microservices”) • Built, released, & operated by independent application teams • Scaled independently
- 29. App Architecture: A Spectrum of Services • Di ff erent locations (K8s, VMs, FaaS) • Di ff erent protocols (gRPC, HTTP, WebSockets, TCP) • Di ff erent load balancing requirements (sticky sessions, round robin) • Di ff erent authentication requirements 29
- 30. Cloud Gateway 30 Real-time Service Discovery Need ADC-like traffic management capabilities: timeouts, retries, rate limiting, load balancing, caching, … Need API Gateway-type management capabilities: authentication, developer portal, metrics, … 1 2 3
- 31. Microservices lead to an even bigger change. 31
- 32. 32 “You build it, you run it” - Werner Vogels, CTO Amazon i.e. you own what you code, from idea to production
- 33. Workflow: Full Cycle Development 33 • App teams have full responsibility (and authority) for delivering a service, and ultimately, value to users • Increase agility by accelerating the feedback loop • https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249
- 34. 34 This is a change in workflow.
- 35. 35 Thesis: The future evolution of the edge will be driven by application architecture, technology, and workflow
- 36. 36 Two Biggest Challenges with k8s & the Edge
- 37. Challenge #1: Scaling Edge Management 37 Development Team Operations / Platform Team
- 38. Challenge #1: Scaling Edge Management
- 39. Challenge #2: Supporting Diverse Edge Requirements 39
- 41. Three Strategies for the Edge with Kubernetes #1: Deploy an Additional Kubernetes API Gateway #2: Extend Existing API Gateway #3: Deploy an in-Cluster Edge Stack 41 https://www.getambassador.io/resources/strategies-managing-apis-edge-kubernetes/
- 42. #1 Deploy an Additional Kubernetes API Gateway • Simply deploy an additional “in-cluster” gateway • Below the existing gateway • Below the load balancer • Management • Development teams responsible • OR existing ops team manages this 42
- 43. #1 Deploy an Additional Kubernetes API Gateway • Pros • There is minimal change to the core edge infrastructure. • Incremental migration easily • Cons • Increased management overhead of working with di ff erent components • Challenging to expose the functionality to each independent microservice teams 43
- 44. #2 Extend Existing API Gateway • Implemented by modifying or augmenting the existing API gateway solution • Enable synchronization between the API endpoints and location of k8s services • Custom ingress controller for the existing API Gateway or load balancer 44
- 45. #2 Extend Existing API Gateway • Pros • Reuse the existing tried and trusted API gateway • Leverage existing integrations with on-premises infrastructure and services • Cons • Workflows must change to preserve a single source of truth for the API gateway configuration. • Limited amount of configuration parameters via Kubernetes CRDs/annotations 45
- 46. #3 Deploy an In-Cluster Edge Stack • Deploy Kubernetes-native API gateway with integrated supporting edge components • Installed in each of the new Kubernetes clusters, replacing existing edge • Ops team own, and provide sane defaults • Dev teams responsible for configuring the edge stack as part of their normal workflow 46
- 47. #3 Deploy an In-Cluster Edge Stack • Pros • Edge management is simplified into a single stack • Supports cloud native best practices: “single source of truth”, GitOps etc • Cons • Potentially a large architectural/responsibility shi ft • Platform team must learn about new proxy technologies and edge components 47
- 48. 48 Wrapping Up
- 49. In Conclusion • Edge/API gateways have undergone a series of evolutions, driven by architecture and tech • Hardware -> so ft ware • Networking Layer 4 -> Layer 7 • Centralized management -> decentralised • Adopting microservices/Kubernetes changes workflow • Scale edge management • Support multi-protocol and cross-functional requirements • Choose your cloud API gateway intentionally (and also your platform components in general) 49
- 50. Many thanks! • Learn more: • www.getambassador.io/kubernetes-learning-center/ • www.getambassador.io/resources/accelerating- kubernetes-for-cloud-native-organizations/ • www.infoq.com/profile/Daniel-Bryant • Find me in: • Ambassador OSS Slack: d6e.co/slack • Twitter @danielbryantuk 50