> Cloud solutions like elastic load balancing are generally engineered for the average use case. Think about the ways you are not like the average.
This might be the case for some things, but many of Google Cloud's "elastic/serverless" products (Load Balancers, App Engine, Pub/Sub, BigQuery, Datastore, etc) can truly scale up from nothing to huge traffic spike without the need for pre-warming and things like that.
Also, networking on GCP is vastly superior to AWS. The VPC is setup with sane defaults and VM instances can communicate privately to other VM instances in any zone or region without needing complicated constructs such as VPN's or NAT instances.
Lastly, Google Cloud is generally cheaper (sustained use-discounts), higher performance, and takes all the lessons learned from AWS and applies them.
The one knock I have on GCP is billing. It is incredibly obtuse. Even the monthly billing invoices I still have a hard time digesting (especially if you have multiple projects under a single billing account).
Really? We've found it to be much easier. The billing section has up-to-date current breakouts and a simple list of transactions for each billing account. There are budget alerts and the best part is the easy export into bigquery which then gives you SQL access for all of it. Add in datastudio and you have BI style analysis and visualizations too. Better than anything else the other clouds have.
Video from GCP Next: https://www.youtube.com/watch?v=qL8kvTb4RbU
By the way, it looks like ALB might be based on nginx, based on the error pages. I wonder if classic ELB is based on HAProxy.
ugh vendor lock-in is the worst :)
Where I work we are saving ... uh ... a lot of money by migrating our workloads over. And they're faster. It's awesome.
Hopefully GCP will start pushing AWS to lower their prices. They charge so much.
Disclaimer: I work for GCP.
Contrast with Google, you start with the confusion that there are two products (cloud endpoints, apigee), and neither really talks about integration with Cloud functions.
That said, it depends on your design/architecture as to whether that is appropriate or not. Sometimes you want that distinct separation. But if that's the case, you should also probably not even be thinking about that low latency case, because you should treat it as a service outside of your control, that may be (and probably should be) cross regionally available (so you might even be crossing the country, for all you know. This presumes the inclusion of latency based routing with a custom DNS, of course, but for a standalone, client facing service, that's what you should be doing anyway).
Obviously there may be a middle ground you want, but I'd say you probably either want to treat it as "your" API, and thus, you can be as pragmatic as you want when accessing it, or you want to treat it as a reusable, completely separate service, that you are a client of, in which case things like location can not be guaranteed, and thus latency is a reality.
It's common enough that when I asked Amazon about it, they already had enough requests that it's on the roadmap.
People use api gateways for all sorts of things like orchestration, tokenizing sensitive data, caching requests, etc, that should have the same interface whether used internally or externally. Sure, I could recreate all that functionality for internal use, but that's one of the supposed benefits of an API gateway...turn what was code into configuration. See products like Apigee, Kong, Tyk, etc.
But, I -did- mention there were caveats. Your correct in tha I should probably not have led with "You probably shouldn't", and -then- gotten more nuanced, though. While I agree that optimizing it to not leave the AWS network would be of benefit, if you reach the point you're calling it via the API Gateway internally, it's a separate service, and if it has -any- high availability requirements, or ever will, you should not be reliant on it not leaving the network (since even without going multi-region with distributed DNS, it may be handled by another AZ, introducing latency).
Products that compete with Amazon's API gateway can do it, though you're right that their product cannot.
Edit: There are also AWS customers that use a different CDN...Akamai, Cloudflare, etc. Decoupling API gateway and Cloudfront would have benefit for them.
Integrating API gateway into our deployment took a little bit of work, but we're happy to have it part of our automated deployment process. We push updates of our swagger spec with AWS CLI to a separate API per environment (dev, staging, and prod-west, prod-east). Each of environment has one API gateways with several stages that we use for green/blue deployments. The stages are green, blue, and public. We deploy to the inactive color (green or blue) smoke test and promote that stage to public. This simulates the same process we do in production and the swap to public is akin to our DNS swap from one side to the other. We were very happy that it wasn't a huge time investment to fit this workflow into our deployment process.
Somehow we missed the fact that because API gateway was tied to CloudFront that it did not support multi regional failover. If we have a service outage in our primary region we swap all of our traffic with DNS to our secondary region (from us-west-2 to us-east-1). In order for us to do a regional failover with API gateway we would need to deprovision the endpoint api.domain.com in the failing region and provision api.domain.com in our failover region. I'm expecting if we have to do a regional failover there is a very good chance that the request to deprovision the endpoint will likely fail. See my AWS forum reply and other's asking for the same feature: https://forums.aws.amazon.com/message.jspa?messageID=761925#...
My team is very much looking forward to this functionality. We have duplicated our infrastructure across multiple regions to mitigate a region outage. We were planning on relying on a dns change to route traffic to a new region.
With the limitations that you have described, our failover process is much more complicated and uncertain.
Given the two regions primary (us-west-2) and secondary (us-east-1). We will need to attempt to disassociate our api.domain.com from primary API Gateway and wait for that operation to complete. After that we must associate our secondary API Gateway with api.domain.com. Its very possible and likely issues on primary that caused us to fail over to secondary may prevent the disassociating from the primary. This is an extremely undesirable side effect as it could leave us with unhandled requests or error responses to api.domain.com.
I wanted to post this here for others suggest alternative workarounds or ideas. We will also follow up with a support ticket.