5 ms·

Google Cloud is great and cheap. But AWS is waaay more ahead in terms of completeness. I've looked into this. The breadth, depth, and polish of AWS is really

Google Cloud is great and cheap. But AWS is waaay more ahead in terms of completeness. I've looked into this. The breadth, depth, and polish of AWS is really impressive. Their API Gateway -> lambda container -> DataStore is amazing. I really wish I could use GCP. :( Hopefully GCP will start pushing AWS to lower their prices. They charge so much.

_0nac 9y ago
Curious: How does that differ from GCP's Cloud Endpoints/Apigee Edge -> Cloud Functions -> Cloud Datastore? Disclaimer: I work for GCP.
- tyingq 9y ago
  Some of it is just documentation and marketing. If you go to the AWS api gateway main page, it talks about serverless/lambda integration right there. They also have specific pages that show how to use them together. Including using them as the endpoint, or using them at a higher level to influence routing to a different endpoint, or modify requests, etc. 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.
- squeaky-clean 9y ago
  In my case the first obstacle (and I haven't looked into it too much) is we have a lot of Lambda functions written in Python and Scala.
tyingq 9y ago
The API Gateway is somewhat limited in that the endpoints are tied to CloudFront. So, if you want to leverage it internally, versus connections from a user's web browser, the request leaves your VPC (and potentially goes quite a ways out) for no obvious reason. It would be nice if they decoupled API gateway from CloudFront.
- lostcolony 9y ago
  If it's internal, you probably shouldn't be using the API Gateway. You can just call the underlying lambda directly through the SDK with invoke and save yourself the cost of the API Gateway, as well as be able to invoke it asynchronously should that be a better fit. 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.
  - tyingq 9y ago
    >If it's internal, you probably shouldn't be using the API Gateway 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.
    - lostcolony 9y ago
      Per your OP, how do you plan on caching requests without it hitting Cloudfront in some way? :P 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).

_0nac 9y ago

Curious: How does that differ from GCP's Cloud Endpoints/Apigee Edge -> Cloud Functions -> Cloud Datastore? Disclaimer: I work for GCP.

tyingq 9y ago
Some of it is just documentation and marketing. If you go to the AWS api gateway main page, it talks about serverless/lambda integration right there. They also have specific pages that show how to use them together. Including using them as the endpoint, or using them at a higher level to influence routing to a different endpoint, or modify requests, etc. 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.
squeaky-clean 9y ago
In my case the first obstacle (and I haven't looked into it too much) is we have a lot of Lambda functions written in Python and Scala.

tyingq 9y ago

The API Gateway is somewhat limited in that the endpoints are tied to CloudFront. So, if you want to leverage it internally, versus connections from a user's web browser, the request leaves your VPC (and potentially goes quite a ways out) for no obvious reason. It would be nice if they decoupled API gateway from CloudFront.

lostcolony 9y ago
If it's internal, you probably shouldn't be using the API Gateway. You can just call the underlying lambda directly through the SDK with invoke and save yourself the cost of the API Gateway, as well as be able to invoke it asynchronously should that be a better fit. 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.
- tyingq 9y ago
  >If it's internal, you probably shouldn't be using the API Gateway 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.
  - lostcolony 9y ago
    Per your OP, how do you plan on caching requests without it hitting Cloudfront in some way? :P 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).