API management on Google Cloud Platform

0
votes

I'm new to Google Cloud Platform and looking for a solution to handle APIs to different environments.

Currently I have an API domain name (e.g. api.company.com) mapped to a GCP load balancer which then distributes requests to google computer engines. This is all setup in one GCP project which is the prod1 environment.

I want to create another prod environment called prod2 as another project. Rather than switching the DNS, I am looking for a way that I can easily reroute api.company.com to prod2 and also maintain non public endpoints for backend apis.

Can I use Google CloudEndpoints to do this? Ideally I would like to set this up in a separate project which can then access the prod1 and prod2 load balancers? If this is achievable, can I have the load balancers non public facing?

Any recommendation or best practice advice would be much appreciated.

1
google-cloud-platform
You mean that with the same DNS name you want to route (dispatch) to the prod1 and prod2 project? - guillaume blaquiere
Yes that's right. But I want to manage it in GCP like an API gateway (preferably in a separate project). - Swordfish
How do you know which request is routed to the prod1 and to the prod2? Do you have a path prefix for this? - guillaume blaquiere
For the moment i would route to only one prod env and then i can switch between them. This allows us to prep an env, data load, test and switchover. In the future we would use paths or wildcard sub domain to identity where to route to. - Swordfish

1 Answers

0
votes

Today, I think there is no GCP product that allows you to do this easily.

Cloud Endpoint have 2 problems:

  • You can't define path wild card. I mean, if you define /path -> prod 1; and you call /path/customer your query won't be routed because /path/customer is not defined. At the end, you have to define all your paths into Cloud Endpoint
  • Here come the second problem: You can't, for now, aggregate several API spec file. Therefore you will need to maintain 1 global file for Prod and for your tests, with the risk of wrong update and outage in production.

Optionally, you can imagine this architecture as workaround

  • Deploy compute engine into another project (prod2) for serving your test API
  • Create a VPC peering between the 2 project
  • Create another route into your load balancer of prod1 project for reaching the peered network of prod2

I never tried this kind of architecture, but it should work.