API Gateways provide functionality like rate limiting, authentication, request routing, reporting, and more. If you've been following the rise in service-mesh technologies, you'll notice there is a lot of overlap with API Gateways when solving some of the challenges of microservices. If service mesh can solve these same problems, you may wonder whether you really need a dedicated API Gateway solution? The reality is there is some nuance in the problems solved at the edge (API Gateway) compared to service-to-service communication (service mesh) within a cluster. But with the evolution of cluster-deployment patterns, these nuances are becoming less important. What's more important is that the API Gateway is evolving to live at a layer above service mesh and not directly overlapping with it. In other words, API Gateways are evolving to solve application-level concerns like aggregation, transformation, and deeper context and content-based routing as well as fitting into a more self-service, GitOps style workflow. In this talk we put aside the "API Gateway" infrastructure as we know it today and go back to first principles with the "API Gateway pattern" and revisit the real problems we're trying to solve. Then we'll discuss pros and cons of alternative ways to implement the API Gateway pattern and finally look at open source projects like Envoy, Kubernetes, and GraphQL to see how the "API Gateway pattern" actually becomes the API for our applications while coexisting nicely with a service mesh (if you adopt a service mesh).

1. API Gateways are Going Through
an “Identity Crisis”
@soloio_inc

2. CHRISTIAN POSTA
• Field CTO @ solo.io
• Author of a few books
• Contributor to many open-source projects
• Architect, blogger, speaker, mentor, leader
https://bit.ly/istio-in-action
@christianposta
christian@solo.io
https://blog.christianposta.com
https://slideshare.net/ceposta

3. 3 FREE COPIES AT END OF THE SESSION:
COMPLEMENTS OF SOLO.IO
https://bit.ly/istio-in-action

4. Identity
Crisis?
A period of uncertainty and
confusion in which a sense of
identity becomes insecure,
typically due to change in
expected aims or role

5. Integration sucks, let’s build APIs
Organizations will always have multiple
systems that need to talk to each other.

6. Definition of “API”
An explicitly and purposefully defined interface designed to be
invoked over a network that enables software developers to get
programmatic access to data and functionality within and
between an organization in a controlled and comfortable way.

7. Managing APIs

8. API Management systems
• Security
• Rate limiting
• Policy enforcement
• Logging
• Reporting
• API documentation
• Sign up
• Monetization plans
• Chargeback/billing

9. API Management reality
• Route everything through
an API Gateway and
series of load balancers
• Metrics collection
• Security enforcement
• Rate limiting
• Governance catalog

10. API Gateway reality
We’ve seen “API Gateway” become synonymous with solving
service-to-service governance and communication problems.

11. Microservices to go faster
• Smaller, independently
deployable services
• Decentralized communication
patterns
• Services own their own state
• Still needed to solve for
service-to-service
communication problems

12. Service to service communication
• Service discovery
• Load balancing
• Metric collection
• Resiliency (timeout, retry circuit breaker, rate limiting)
• Strong identity and security
• Policy enforcement
• Traffic control, routing, fine-grained request flow
• Distributed tracing

13. Service mesh for service to service

14. Service mesh functionality
• Fine-grained traffic control (at request level)
• End-to-end encryption with strong Identity
• Network-level (request) metric collection and tracing
• Policy enforcement
• Request-level resilience

15. Service mesh for service-to-service
Service mesh more adequately solves for, service-to-
service communication problems than a traditional API
Management solution/gateway, and is abstracted from
any particular deployment platform.

16. Service-to-service communication

17. Evolution of the term API Gateway…
So what about API Gateways?

18. Common wisdom
API Gateways: for north/south traffic
Service Mesh: for east/west traffic

19. Service-mesh ingress gateway
”north/south” traffic
”east/west” traffic
Some say the distinction between mesh and API Gatway
is north/south vs east/west traffic management?

20. Kubernetes ingress gateway

21. Federated cluster/mesh
Where, exactly, is the
north/south traffic?

22. API Gateway “Identity Crisis”
• Centralized, shared infrastructure that facilitate the exposure
and governance of existing APIs to external entities?
• Centralized, shared infrastructure that handles service-to-
service traffic?
• Cluster ingress sentries that tightly control what user traffic
comes into the cluster or leaves it?
• “North/south” traffic controller in a service mesh?

23. First principles are important
Let’s step back for a second.
What is the API Gateway design pattern?

24. Pattern?
https://twitter.com/starbuxman

25. API Gateway Pattern
“A service that’s the entry point into the
microservices-based application … is
responsible for request routing,
API composition, protocol translation …
and edge functions like authentication,
authorization, rate limiting, caching, et. al.”
See also: https://microservices.io/patterns/apigateway.html
https://www.manning.com/books/microservices-patterns

26. API Gateway Pattern: forces at play
• API surface intentionally smaller than what clients need (see
microservices)
• Clients become coupled to the architecture
• Microservices dilutes the notion of “what is an application”
• Service-to-service protocols not consumable outside the
architecture
• Clients on non-uniform networks with different latency and
bandwidth assumptions
• Should hide heterogeneous application architectures

27. API Gateway Pattern: what it does
• Tailored API for different kinds of clients
• Abstracts backend services, protocols, message shapes, etc
• Powerful matching/routing, discovery, transformation,
aggregation, protocol translation
• Backends for front-ends
• A developer-first construct
• Intended to be decentralized and change at the pace of your
applications
• Network-level functions including rate-limiting,
authentication/authorization, caching, metrics collection

28. API Gateway Pattern: what it does

29. API Gateways build flexible APIs

30. API Gateways build flexible APIs

31. API Gateways build flexible APIs

32. API Gateways build flexible APIs
API gateways are not about service-to-service communication.

33. API Gateways build flexible APIs

34. Build API Gateways with:
• Spring Cloud Gateway
• Netflix Zuul
• IBM Loopback
• Solo.io Gloo
• WSO2 Ballerina
• Apache Camel/Spring Integration

35. Meet Gloo, a next-generation API Gateway
https://github.com/solo-io/gloo

36. What is Gloo?
● Open-source; ASLv2
● Built on Envoy Proxy
● Routing engine for “function” composition
● SOAP, Swagger/REST, gRPC, HTTP/1, HTTP/2,
WebSockets
● Transformations
● Powerful discovery mechanisms
● Extensible control plane
● GraphQL Engine (https://sqoop.solo.io) https://gloo.solo.io

37. What is Gloo?
● Weighted routing, canary releases
● Offload authentication/authorization
● OAuth flows
● Plugin in to platform auth services
● TLS termination, passthrough, mTLS
● Rate limiting
● Dynamic configuration
● Deploy to any infrastructure
● Kubernetes native (when deployed to Kubernetes) https://gloo.solo.io

38. Gloo is based on Envoy Proxy
● Purpose built to make application network traffic
resilient and observable
● Good performance, written in C++
● Massive community adoption
● Vibrant, responsive community
● Dynamic configuration APIs
● Graduated project in CNCF
Used by:
https://envoyproxy.i
o

39. Gloo control plane

40. Gloo composes functions
● Request path
● Method
● Headers
● Body shape/type
● AWS Lambdas
● Google Cloud
Functions
● Azure Functions
func updateShoppingCart(custId int, item Item) Cart

41. Gloo composes functions
● Request path
● Method
● Headers
● Body shape/type
● AWS Lambdas
● Google Cloud
Functions
● Azure Functions

42. Functions?
● Request path
● Method
● Headers
● Body shape/type
● AWS Lambdas
● Google Cloud
Functions
● Azure Functions

43. Use Gloo to build a API Gateway
foo.io/customer foo.io/order bar.io/account bar.io/order
Monolith Microservices Cloud Functions Hybrid Application

44. Gloo companion project: Sqoop
Query
Monolith Microservices Cloud Functions
Result
https://sqoop.solo.io

45. Gloo companion project: Sqoop
https://sqoop.solo.io
● OpenSource GraphQL engine built on top of Gloo
● Configure GraphQL Schemas and Resolvers
● Default use Gloo upstreams as resolvers
● Leverage Gloo
○ Caching
○ Transformations
○ Security
○ Routing
○ Observability
● Can extend resolvers
● Part of newly announced GraphQL Foundation
http://bit.ly/graphql-foundation

46. Gloo as Kubernetes-native API Gateway
$ glooctl add route
--path-exact /api/findCustomer
--dest-name customer-upstream
--rest-function-name findById
Use powerful Gloo CRDs to
configure Gloo’s Gateway:
● Gateway
● VirtualService
● Upstream
● Proxy

47. Gloo is complementary to Istio/service mesh

48. Gloo is complementary to Istio/service mesh

49. Check out Gloo!
https://gloo.solo.io https://sqoop.solo.io https://supergloo.solo.io

50. For more information
● https://solo.io/glooe-trial
● https://solo.io
● https://medium.com/solo-io
● https://twitter.com/soloio_inc
● https://gloo.solo.io
● https://sqoop.solo.io
● https://supergloo.solo.io
● https://squash.solo.io

51. HOW BOOK WINNERS WILL BE DECIDED:
https://bit.ly/istio-in-action
For everyone else: 40% off with code:
cpistio
Tweet with @christianposta and hashtag:
#Gloo and #Chicago
Example:
“Thanks @christianposta for the amazing
talk on APIs, service mesh, and of course,
#Gloo in #Chicago!”
The 1st, 5th, and 15th person will get a free copy!

52. Thank you
@soloio_inc