What is an API microgateway?

Complimentary article from David McKenna, VP Engineering at Axway.

One tenet of a successful microservice strategy is the adherence to Conway’s Law, which results in an organization where there are independent teams creating independent microservices. This brings challenges to operators and security personas who want a central control and governance for API traffic flowing within the organization. This is where an API microgateway is helpful.

An API microgateway is a proxy that sits close to the microservice. As a result, it provides value to the developers by extracting governance, discovery, observability, and stability in a reusable agent and gives value to the operators by exposing the Policy Enforcement Point (PEP) and Security Controls in a centralized control panel.

And, thus, you end up with a system that is a service mesh allowing one to control externally service monitoring and tracing, request (version) routing, resiliency testing, security, and policy enforcement, etc., in a consistent way, across the services, for the application.

API microgateway deployment

Every microservice will have a corresponding API microgateway. The API microgateway will follow the sidecar application pattern. A sidecar application is deployed along each microservice that is deployed.

It is conceptually attached to the “parent” service, in the same manner, a motorcycle sidecar is attached to the motorcycle–hence the name. A sidecar runs alongside the service as a second process and provides “platform infrastructure features” (see the feature list below):

The microgateway pattern does not reduce the number of network transactions. In fact, for internal API calls (i.e., service to service) it will actually increase the calls. That is, say servA want to call servB. The flow would be servA calls servB via its local MG, this request gets routed to servB local MG and then onto servB. So you have servA -> servA MG -> servB MG -> servB. This is more hops than servA -> Gateway -> servB.

The big advantage for resources is the distributed nature of MGs and so you distribute resource usage rather than centralizing on a monolithic Gateway.

Traffic management

“The network should be transparent to applications. When network and application problems do occur, it should be easy to determine the source of the problem.” envoyproxy.io project
The API microgateway is responsible for controlling all traffic inbound and outbound to parent service. This means that it will be responsible for providing:

• TLS Termination
• Failure patterns for outbound calls
  • circuit breaker ala hystrix
  • retry with backoff
• Load balancing (i.e., Round Robin, random, weighted, etc.)
• Rate limiting of requests
• Health checks of services
• Discovery of services from the service registry
  • DNS
  • Kubernetes
  • Consul
  • Docker
  • etc.

As a result, API calls between services become more reliable and make the network more robust in the face of adverse conditions (see Fallacies of distributed computing).

Observability

Metrics and tracing (request + response).

• Metrics of each service in the system are available without having to instrument each service, resulting in consistent metrics across a fleet of services
• Ability to trace the flow of requests across services (dapper/zipkin)
• Access Logging

Policy enforcement point

The API microgateway will be acting as a Policy Enforcement Point (PEP) and will enforce policies that will allow/disallow requests and responses. Policies could include AuthN, AuthZ and content validation.

Configuration

Source Code Management (SCM) friendly and stored on disk as files.

Central governance

Edge gateway/Microgateway communication

Discover the checklist for 10 strategic API action items to drive digital success.

Click Here