-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ADR] API Gateway #34
Comments
Remember that ADRs are publicly available hence do not include any confidential information in the issue description! |
Are there any compelling solutions in GCP @piotrczyz? |
As far as I can see there are possibilities using CLI for both AZ and GCP. |
As far as I read and observed, if we consider creating services as a part of deployment pipeline then it looks like a better fit will be GCP and either API Gateway or Cloud Loud Balancer from Google Cloud. We can always use Terraform to manage our CI/CD. @rvanoord |
Does Google have a good offering that would work cross-cloud @piotrczyz? Google API Gateway looks interesting, but perhaps it only supports Google services (like cloud run)? |
It looks like Google has something to offer for hybrid connectivity, @rvanoord |
Context
We would like to add a communication layer between all our frontends and our back services.
As a goal, there should be an easy way to configure/add a new service. Everything should be configurable as a pipeline (Infrastructure as a code).
We want to provide an unified way of communication with our services so that will be easily accessible for external applications or developers.
Decision
After an investigation and consultations, we decide to go for Azure Front Doors.
In general, using API gateway we're not binded to a programming language. We can use whatever language we know that supports HTTP calls.
Although, almost all our applications are hosted on Google and a natural way would be to start using a service provided from Google. But we consider using Azure as a long-term strategy for our systems and it was a indication of our choice.
Cloud Loud Balancer from Google supports only services hosted on Google. Azure Front Doors is a global load balancer and we can use it both for services hosted either on Azure or Google as long as Azure Containers Apps go out of Preview.
Consequences
Possibly, there may occur some latency between Azure Front Doors and Cloud Run but we can always move dockerized application to Azure.
Alternatives
Azure Front doors with CDN
https://docs.microsoft.com/en-us/azure/frontdoor/front-door-overview
Both Azure Front doors and Azure Application Gateways are layer 7 (HTTP/HTTPS) load balancers.
Pros
Going to GA May 1st, 2022.
Azure Application Gateway
https://docs.microsoft.com/en-us/azure/application-gateway/overview
could be used as a Application Gateway Ingress Controller add-on for AKS cluster link
a regional service
Proxy+WAF
A simple application with implementation for Reverse Proxy + WAF
https://auth0.com/blog/building-a-reverse-proxy-in-dot-net-core/
This is a solution per region so we won't get any benefits of global caching as we have for e.g Front Doors.
Possible solutions:
Konghq
https://konghq.com/
We didn't consider that as it costs $250 / month. For our needs there are better suitable solutions.
Cloud Load Balancer | Google Cloud
https://cloud.google.com/load-balancing
For applications in GKE, GKE Ingress controller is recommended that manages the load balancing.
For deployment, Terraform module can be used link
API gateway | Google Cloud
https://cloud.google.com/api-gateway
For .NET application you can get OAS from link
/swagger/v1/swagger.json
for you application. There is a possibility to deploy an API on existing API Gateway linkDeployment https://cloud.google.com/api-gateway/docs/deployment-model
The text was updated successfully, but these errors were encountered: