5 ms·

This is definitely a post based in experience, but maybe not based on broad expertise in using these tools. I don't want to pick apart the entire post, but I w

This is definitely a post based in experience, but maybe not based on broad expertise in using these tools. I don't want to pick apart the entire post, but I will say that the Lambda + API Gateway example is maybe the best example of jumping into the cloud-native world with blinders on. Just about every modern programming language has a toolset right now that will do the work of generating a CF template for you that creates an API gateway that forwards all HTTP routes to a single Lambda, and then that Lambda is responsible for handling the actual routing of that request. Examples include Zappa, ClaudiaJS, and Ruby on Jets just to name a few. I can't imagine providing a feature-rich web application in Lambda without this kind of abstraction. Not knowing that such tooling exists, or explicitly choosing not to use such tooling, and experiencing pain as a result seems to be common theme in this article. If you dive into architecting a system using AWS's product offerings without understanding the tradeoffs you're making, you will experience greater cost and greater friction -- hands down.

dayjah 6y ago
Yeah, missing the proxy pass option will definitely burn a prospective Lambda user. I also felt a similar tinge when the post talks about KCL. Yes, you use it, and yes there are rules about output streams - but they all make sense when deployed in fairly complex environments. I can’t remember when I last used stdout for logging outside of greenfield development. Once it’s on prod everything goes to stderr and is highly structured. Similar sentiments about Cognito. At some point of complexity you must have a server in between using the Admin* range of commands. If you want their “get going quickly” then yes, there are trade offs like WebViews. That said; I’ve never used Auth0 - so insert a Luddite warning here. Finally, one hundred percent agree on CF.
- jacobra2 6y ago
  Could you elaborate on the proxy pass option piece?
  - davidgh 6y ago
    https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html https://docs.aws.amazon.com/apigateway/latest/developerguide... From the article: In Lambda proxy integration, when a client submits an API request, API Gateway passes to the integrated Lambda function the raw request as-is. ...and: You can set up a Lambda proxy integration for any API method. But a Lambda proxy integration is more potent when it is configured for an API method involving a generic proxy resource. The generic proxy resource can be denoted by a special templated path variable of {proxy+}, the catch-all ANY method placeholder, or both.
- redisman 6y ago
  Another pretty basic Lambda thing the author didn’t mention is the alias feature. So rather than having users-api-dev, users-api-qa - we just have users-api and it has a alias for each environment. The environment variable management is not amazing but just using a key-value JSON {dev: {a: “bc”}} works fine. There’s also truly no reason one lambda function can’t have a collection of APIs (using the proxy method from API gateway). It’s literally no different from any other micro service setup. You can pick any abstraction for a function to cover.
  - Aeolun 6y ago
    If you start trying to work around the limits of your abstraction, maybe you just chose the wrong one in the first place. This is what seems to happen when working with Lambda for me.
mandarg 6y ago
> I can't imagine providing a feature-rich web application in Lambda without this kind of abstraction. This reminded me of a caveat about using some of these abstractions – which is that they are still subject to the limits and restrictions of the underlying platform. We discovered this the hard way once when an automatically generated function name or something was over the limit in prod (this issue [1] describes a similar problem). We did not catch this in dev because "dev" is one character under "prod" and our autogenerated name in dev hadn't put us over the limit. That was an interesting exercise in leaky abstractions. [1] https://github.com/serverless/serverless/issues/2856 https://github.com/serverless/serverless/issues/2856
FireBeyond 6y ago
> Not knowing that such tooling exists, or explicitly choosing not to use such tooling, and experiencing pain as a result seems to be common theme in this article. If you dive into architecting a system using AWS's product offerings without understanding the tradeoffs you're making, you will experience greater cost and greater friction -- hands down. Which I think is one of the underlying points of the article. > Many a startup has fallen prey to ElastiCache. It usually happens when the team is under-staffed and rushing for a deadline and they type in Redis into the AWS console: I think this is a good article in the sense of "these are things that may or will bite you if you've not put a bit of thought into them". Even the replies on this story upstream hint at that, with people debating Redis' durability, based on this: > It’s best to design your system assuming that redis may or may not lose whatever is inside. completely ignoring the follow up: > Clustering or HA via Sentinel, can all come later when you know you need it! It's like the first sentence was read and people leaped to the keyboard to reply passionately.
psanford 6y ago
The API Gateway v2 HTTP stuff makes this even easier[0]. I switched some old services over from the v1 stuff (using '{proxy}' routes) to the v2 API and I was a lot happier. I especially like that v2 has an option for Auto-deploy. I'm sure the manual deployment stuff is really useful to some people but for my little projects it was a real pain to have to remember to trigger a new deployment any time I mad a change. [0]: https://aws.amazon.com/blogs/compute/announcing-http-apis-for-amazon-api-gateway/ https://aws.amazon.com/blogs/compute/announcing-http-apis-fo...

dayjah 6y ago

Yeah, missing the proxy pass option will definitely burn a prospective Lambda user. I also felt a similar tinge when the post talks about KCL. Yes, you use it, and yes there are rules about output streams - but they all make sense when deployed in fairly complex environments. I can’t remember when I last used stdout for logging outside of greenfield development. Once it’s on prod everything goes to stderr and is highly structured. Similar sentiments about Cognito. At some point of complexity you must have a server in between using the Admin* range of commands. If you want their “get going quickly” then yes, there are trade offs like WebViews. That said; I’ve never used Auth0 - so insert a Luddite warning here. Finally, one hundred percent agree on CF.

jacobra2 6y ago
Could you elaborate on the proxy pass option piece?
- davidgh 6y ago
  https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html https://docs.aws.amazon.com/apigateway/latest/developerguide... From the article: In Lambda proxy integration, when a client submits an API request, API Gateway passes to the integrated Lambda function the raw request as-is. ...and: You can set up a Lambda proxy integration for any API method. But a Lambda proxy integration is more potent when it is configured for an API method involving a generic proxy resource. The generic proxy resource can be denoted by a special templated path variable of {proxy+}, the catch-all ANY method placeholder, or both.
redisman 6y ago
Another pretty basic Lambda thing the author didn’t mention is the alias feature. So rather than having users-api-dev, users-api-qa - we just have users-api and it has a alias for each environment. The environment variable management is not amazing but just using a key-value JSON {dev: {a: “bc”}} works fine. There’s also truly no reason one lambda function can’t have a collection of APIs (using the proxy method from API gateway). It’s literally no different from any other micro service setup. You can pick any abstraction for a function to cover.
- Aeolun 6y ago
  If you start trying to work around the limits of your abstraction, maybe you just chose the wrong one in the first place. This is what seems to happen when working with Lambda for me.

mandarg 6y ago

> I can't imagine providing a feature-rich web application in Lambda without this kind of abstraction. This reminded me of a caveat about using some of these abstractions – which is that they are still subject to the limits and restrictions of the underlying platform. We discovered this the hard way once when an automatically generated function name or something was over the limit in prod (this issue [1] describes a similar problem). We did not catch this in dev because "dev" is one character under "prod" and our autogenerated name in dev hadn't put us over the limit. That was an interesting exercise in leaky abstractions. [1] https://github.com/serverless/serverless/issues/2856 https://github.com/serverless/serverless/issues/2856

FireBeyond 6y ago

> Not knowing that such tooling exists, or explicitly choosing not to use such tooling, and experiencing pain as a result seems to be common theme in this article. If you dive into architecting a system using AWS's product offerings without understanding the tradeoffs you're making, you will experience greater cost and greater friction -- hands down. Which I think is one of the underlying points of the article. > Many a startup has fallen prey to ElastiCache. It usually happens when the team is under-staffed and rushing for a deadline and they type in Redis into the AWS console: I think this is a good article in the sense of "these are things that may or will bite you if you've not put a bit of thought into them". Even the replies on this story upstream hint at that, with people debating Redis' durability, based on this: > It’s best to design your system assuming that redis may or may not lose whatever is inside. completely ignoring the follow up: > Clustering or HA via Sentinel, can all come later when you know you need it! It's like the first sentence was read and people leaped to the keyboard to reply passionately.

psanford 6y ago

The API Gateway v2 HTTP stuff makes this even easier[0]. I switched some old services over from the v1 stuff (using '{proxy}' routes) to the v2 API and I was a lot happier. I especially like that v2 has an option for Auto-deploy. I'm sure the manual deployment stuff is really useful to some people but for my little projects it was a real pain to have to remember to trigger a new deployment any time I mad a change. [0]: https://aws.amazon.com/blogs/compute/announcing-http-apis-for-amazon-api-gateway/ https://aws.amazon.com/blogs/compute/announcing-http-apis-fo...