Complimentary article from David McKenna, VP Engineering at Axway.
One of the tenets of 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 which 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 also 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 externally control service monitoring and tracing, request (version) routing, resiliency testing, security and policy enforcement, etc., in a consistent way across the services, for the application as a whole.
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 alongside 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 feature list below):
Source Code Management (SCM) friendly and stored on disk as files.