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):
Source Code Management (SCM) friendly and stored on disk as files.
Edge gateway/Microgateway communication
Discover the checklist for 10 strategic API action items to drive digital success.
“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:
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).