skip to Main Content

My question is regarding utilizing the API gateway pattern with microservices as it relates to local development on individual developer machines.

We have a small microservice architecture setup which consists of an API gateway (We were using Envoy but are flipping to NGINX) with a single microservice behind the gateway (soon to be many more microservices).

This is a very basic microservice environment we are using to test out our microservice architecuture including our API gateway and K8s deployment to QA.

The API gateway and microservice are containerized into docker containers and are launched on local development machines (visual studio/c# ) utilizing docker compose right now.

When we docker compose locally we spin up both the api gateway and the microservice(s) which sit behind the gateway. On our local dev machines we then test calls through the api gateway container so that developers can verify the api gateway is configured properly and flowing traffic as expected through the microservice(s) sitting behind it.

We were curious ( Heres the Question) if other dev teams using an API Gateway pattern typically launch the api gateway locally when developing on dev machines and test the gateway on their local machines prior to pushing the containers to a QA environment.

We thought the NGINX API gateway would deploy directly into Kubernetes which we would like to run in our QA/Prod environments and we felt that local developer testing of the traffic through the API Gateway would be helpful prior to deploying to K8s in QA.

However, NGINX appears to have a separate ingress controller image which is used in Kubernetes and the configuration of the API gateway seems that it may not match the configuration of the NGInX ingress controller. So we are second guessing ourselves as to whether it is beneficial to launch the API gateway at all locally on our development machines while doing development or not. We’d like to hear what other teams do.

2

Answers


  1. Running it locally is a good approach when your gateway is difficult to debug when running on remote machines.

    To have a good distributed developer experience, I think, is necessary to have a good instrumentation to log and validate all the api gateway routes and it’s behaviors.

    Without that it could be painful. Local debugging can lack some of real infrastructure scenarios. And discovering it in production is not an option 🙂

    Login or Signup to reply.
  2. Adding to Kubernetes part, NGINX Ingress controller is generally used as it handles most API gateway use cases in Kubernetes. But there are cases, when both an Ingress controller and an API gateway can be used, here’s some useful info on it: https://www.nginx.com/blog/how-do-i-choose-api-gateway-vs-ingress-controller-vs-service-mesh/

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search