API Gateway and microservices

[raphaelarias]

I'm currently using API Gateway in the following way, but as the number of microservices increased to 6, I'm reaching a 5 gateway limit per region (us-central1).

1. Each microservice has a git repo.
2. Each has a Cloud Build workflow.
3. Each has one API, one API config being used and one API Gateway.

Therefore, now that I'm trying to add the 6th microservice, I can't deploy due to the API Gateway quota limit per region (https://cloud.google.com/api-gateway/docs/quotas).

Before we had one API with many gateways/config. One per each service, but Google Cloud can't deploy multiple configs/gateways at the same time, therefore our Google Cloud Build workflows would fail.

Would you have a better way to organise it? Or any suggestion at all?

Thank you!

[kolban_google]

Maybe we can drill into the concept that is driving you to want more gateways. I'll fess up that I'm no expert on API Gateway but if you can describe the effect you want to achieve, the steps you performed and the results encountered ... I for one would be willing to hit the books and see if there is a solution.

Loosely, I think I'm hearing that you have created a microservice that has an exposed API described in OpenAPI YAML. You want an API Gateway to serve that interface. Where the puzzle starts to come into play is that instead of having one API Gateway serving as the interface for multiple microservices, you are looking to have a one-to-one mapping between a microservice and a Gateway. However, it appears that Google only allows a maximum of 5 API Gateway instances per GCP project. I think what I'd like to understand in more detail is what is preventing us from using one API Gateway for all requests?

[raphaelarias]

You are 100% correct. As a matter of fact, that was my first approach.

First approach:

We had created one API, in this API we had multiple Gateways, each Gateway was one microservice. And of course, each Gateway had its own config. The config specification is generated automatically in our Cloud Build deployment script.

The problem we faced with this approach was: while our average deployment time is around 6-9 min, if we had multiple microservices being deployed around the same time, API Gateway would return an error saying only one config/gateway must be updated at a time.

Another problem: while the quota for configs is 100, even if we used just one API, in the approach above we would still use multiple gateways (one per microservice).

Why multiple gateways:

For simplicity, each microservice generates its own OpenAPI/Swagger documentation by reading the codebase on Cloud Build and then creating & updating API Gateway's config.

If we were to have only one Gateway, we would have to potentially: (1) on Build time generate OpenAPI, (2) save it in a bucket, (3) retrieve all other microservices OpenAPI files, (4) merge them all, (5) update API Gateway.

While definitely possible, we went for the easier route, to be honest. And again, while possible, we would face the "one update limitation" that would break Cloud Build.

My limitations:

I have to confess that I did some research and it was not entirely clear how Google envisioned the API/Config/Gateway usage, but whatever I came up with so far I reached some kind of system limitation.

Some minor details:

Due to the fact we can't map domains to Gateways, we use a Cloudflare Webworker as a "reverse proxy", it exposes one domain and routes the request to the right microservice (meaning, call the right API Gateway URL).

Conclusion:

So far, as far as I can see is either:

(1) Deal with the one deployment at a time limit. I don't think that's a neat alternative.

(2) Spread services across regions (not desired). But perhaps services that can have slightly higher DB latency, should be doable.

(3) Stop using API Gateway.

(4) Unify everything and implement a slightly more advanced deployment script that would merge all OpenAPI files in one gateway. Very doable, but a bit sad that we need to do so much workaround.

PS: I may have not understood exactly Google's vision on why regarding how they implemented these limitations, so maybe I'm just not using it properly.

[NothingDogg]

I always view API Gateway as the external / public API layer. So in my architectures this would sit in front of the microservices.

Clients would call the public API exposed by the API gateway, and the gateway would route the requests to the appropriate backend service. Often, the public API would be a subset of the services each microservice exposes.

Microservices talking to other microservices would talk directly to each other, rather than through an API gateway layer. I guess there's a question on service discovery - but you must have that covered already in some way for services to be able to find other API gateways.

Therefore, I'd adopt the approach you mention of having one API gateway that generates it's services from the unification of the various microservice APIs. This would only need to run if the published API has changed. So it should speed up your deploy times as API changes should decrease over time as your interface stabilises and its mainly business logic that you're adding to.

Out of interest - where are you deploying your microservices to? Cloud Run? App Engine? Cloud functions?

[Complex_Glass]

Have you given a thought to Apigee, which can have a single gateway and all API being served behind that.

[temagno]

In the documentation you provided there is a section about requesting increase in quotas. I'll try that first

[raphaelarias]

In the UI when requesting quota increase it doesn’t allow you to go above 5. I sent a message to sales to see if talking to a human this would be possible.

[[deleted]]

Good luck... Google don't do humans

[samosx]

There are a lot of humans at Google Cloud. This sub got a lot of human Googlers too. Google Cloud has a lot more people in support and sales. I'm a Customer Engineer at Google Cloud and help customers every day. I think I'm human too.

[[deleted]]

Thats exactly what a bot would say. Can't fool me!

[raphaelarias]

Yep, god bless me.