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