I'm facing a problem that I can't find ways to easily solved it on Google Cloud.
Today, I have an AWS Account with several systems running on a Kubernetes cluster, Lambda functions and Elastic Beanstalk. For accessing them, I use an API Gateway like this:
Domain xpto.com
|----------------> xpto.com/login -> Lambda Function
|----------------> xpto.com/users -> Kubernetes Cluster
|----------------> xpto.com/employee -> Elastic Beanstalk
So, I have the same domain with different paths and each of those paths is redirected to one specific place where a service is running.
The problem is, I didn't find a way to "translate" this API Gateway rules to GCP.
Is there a native way to it? And if isn't, how do you guys recommend a way to solve this (DNS, reverse proxy, ...)?
Thanks in advance for the help.
It appears that Google Cloud Endpoints may be a consideration. This allows one to expose an API gateway using OpenAPI specification.
One of the core concepts is the notion of the x-google-backend element which allows one to define distinct endpoints for different exposed services.
See also:
Cloud Endpoints documentation
Related
I've been trying to migrate my solution from Google Cloud App Engine to Google Cloud Run and have been struggling a lot.
I have 3 services in app engine for each staging environment, let's call them api, front1, front2. front1 has custom domain name assigned www.example.com, as well as staging subdomain www.dev.example.com. Using dispatch.yaml rules I route requests to appropriate services, for example: requests containing api/* are routed to api service, default path routes to front1, /foo* routes to front2. Everything is working there perfectly well, however, hosting the solution on Cloud Run would decrease the costs a lot.
So at the moment, I am really struggling to understand how could I fully replicate this behavior in Cloud Run. I've tried following firebase routing, but it requires to host an app on Firebase as well and doesn't route all traffic for route /api/** to my api service.
I've tried following this article, but I cannot select my service since I selected Internet Network Ednpoint Group option for backend type, which only can point to a single url. Also, I am not sure if it will support wildcard routing there.
I'd highly appreciate any help here, I am totally out of options at the moment.
Good day all,
Scenario:
I am building a web application based on ASP.NET Core Zero Framework. This web application will utilize both front-end components such as login page, reports, etc. as well as exposed RESTFUL services. This application needs to be hosted in AWS.
Requirements:
ASP.NET Core application.
MVC as front-end
Restful API's as back-end
Authorization decoupled from API's (AWS Cognito)
Problem:
I am not sure if I should use AWS Fargate for everything or AWS Lambda.
If I use AWS Fargate, how would I use AWS API Gateway to add authorization to my API's. The fargate tasks run in a VPC and API Gateway cannot access them.
Question:
What would be the best solution, Fargate or Lambda or something completely different.
Kind Regards
Simon Erasmus
AWS container service team member here. This is a very open ended question whose answers will most likely be based on opinions and preferences. These questions often don't lend well on Stackoverflow. In general we see Fargate being used for deployments that implement the very traditional service model associated with standard compute resources (e.g. EC2 or containers) where you launch a process and that process is long lived to accept connections. Lambda is used when you can re-factor your code to work with a specific programming model (function). Many customers are confused by the fact that "Lambda supports containers" but that is limited to the packaging format (Vs. Lambda traditional packaging which is zip). In other words, Lambda supporting containers doesn’t mean you can run ANY container image on Lambda. See here for more background.
We, anecdotically, more commonly see API GW being used with Lambda and ALB/NLB being used with Fargate but it is indeed possible to use API GW with Fargate as well (see here for an example).
Currently we are using express framework with in firebase cloud functions and we would like to have same api distributed on different regions.
Currently this is how it is exported now.
exports.api = functions.region("asia-east2").https.onRequest(app);
As our users are distributed all over globally, is there any way we can make sure the api request hits the nearest region function for faster access and low latency?
This is a little more complex that one might think (at least to my humble knowledge), the short answer is you can't do it by default, this is more like HTTPS load balancer.
Your functions are unique, "the trick" is to route your user to the client deployed on the nearest region. Google Cloud DNS is your friend here (but a not as cool friend as AWS Route53, I left a blog post to get you started). You can get the nearest nameserver taking advantage of the anycast network, but that is as far as you go. I'm not sure what are your implementation details but these resources helped to get started:
https://cloud.google.com/load-balancing/docs/https/https-load-balancer-example
https://cloud.google.com/dns/docs/overview#performance_and_timing
https://aws.amazon.com/blogs/aws/latency-based-multi-region-routing-now-available-for-aws/
Again, it's not about routing the functions, it's about routing the traffic to the client that point to that function, sadly in my case, I end up using AWS Route 53's latency/geo so, I don't have too many details here.
I'm trying to quickly setup a gRCP-endpoint instance on GCP but they seem to be only accessible from inside GCP.
The thing is you can have an endpoint that is managed and it will have a PROJECT_ID.appspot.com URL.
Also, can a gRPC endpoint be publicly accessible ? Is it recommended ?
pRPC is one solution, as I am using golang.
Following this post I might use it. It allows to do gRPC on appengine, without the streaming capabilities, which is fine for me now.
Hope someone has a better answer.
In other words, what part of Google Cloud Endpoints is not in the SDK?
I've seen several people saying that simply running their application elsewhere doesn't work. For exaple, see: https://groups.google.com/forum/#!searchin/appscale_community/endpoints/appscale_community/BFagV00RUcU/taaAoV5mxNEJ
What part of Google Cloud Endpoints is not in the SDK? Are there any initiatives going to try to implement that?
Endpoints has two components. The first is the SDK, and the second is the API proxy. In theory, both could work on other platforms, but the reality is that you would need to really understand the finer details of the interaction between the two to execute it. You could also in theory try to use the dev server servlets to run on other platforms. I make no guarantees about the robustness of either solution.