The API Gateway to Kill all Monoliths
Maurício Linhares / @mauriciojr / Software Engineer at Stripe (previously DigitalOcean)
Once you get good at microservices...
... it will get crowded
Teams will focus more and more on building smaller apps
Clients don't want to know about all your microservices
They want an unified and easy to use API
For clients
- Centralized source of information
- Shared authentication and authorization
- Common call and error handling patterns
- Common communication format
But teams also want freedom to move at their pace
For teams
- Self service routing layer
- Full control over deployments
- Freedom to use different communication patterns when needed
We're at odds here
One side wants less change the other wants more
We need more Layers!
The API Gateway
Goals
Expose unified API to clients
Clients get one single API that hides the complexities about knowing every single microservice that exists
Share common logic for backend services
Logic that can be shared across services (like authentication and authorization) lives at the gateway instead of services.
Translate protocols and data formats
Be it legacy, monoliths or microservices, the gateway can translate protocols and formats so that clients don't have to know about it.
Hide backend implementation details
Killed the monolith or got a new microservice replacing an old one? The gateway hides the details and clients continue to behave as if nothing changed.
Classic proxy support
- Rate limiting
- Load balancing
- Tracing
- Service discovery
- Feature flipping
Many instead of one
Backends for frontends (BFFs) are just one API gateway for every frontend you're serving.
GraphQL
You can build an API gateway as a GraphQL server and have all your clients talk to it, hiding how the whole infrastructure works as well.
How are we doing at DigitalOcean?
3 Rails monololiths
One shared rubygem with base code
July, 2016
Edge Gateway project starts
October, 2016
Starts serving production traffic
December, 2016
First all new microservice integrated
October, 2020
Still going!
What is it?
- Internal DigitalOcean API gateway
- Built in Golang
- Implements shared features currently available at the monoliths
Monoliths and microservices
Microservices are building new functionality and also slowly moving features out of the monolith.
Authentication
Authentication and rate limiting happen at the gateway, services receive the requests with metadata already filled in and then perform the operation.
Applications don't talk to the gateway
Apps register themselves at the route management service and the gateway talks to this service to figure out where to send requests.
Gateway then forwards them the requests
Authentication and metadata is sent over HTTP headers
Headers approach removes dependency
Applications in any language can read the headers and make use of then. They don't depend directly or call the gateway to do their work.
Gateway or application updates do not affect one another
What made most of the difference?
- Documentation
- Sane and easy to use defaults
- Free metrics and dashboards
- Self service solution
- Reliability
Where did we fail?
- Feature parity with existing monolith
- Being more direct in team-to-team communication
- Lack of guidance for teams without much Golang experience
- Better route validation and route wildcards
Are we ever going to kill the monoliths?
Questions?
I have a question!
