3 ms·

I read the entire article, and my first thought is... why? Why go through all that complexity? How much money does this actually save over writing a regular ser

I read the entire article, and my first thought is... why? Why go through all that complexity? How much money does this actually save over writing a regular server to prompt favoring this approach? Wouldn't this have a similar cost as a regular server if you get regular activity, minus all the complexity? What happens when your lambdas get DDoSed, do you get overcharged?

empthought 6y ago
https://aws.amazon.com/api-gateway/faqs/ https://aws.amazon.com/api-gateway/faqs/ “ Q: How can I address or prevent API threats or abuse? API Gateway supports throttling settings for each method or route in your APIs. You can set a standard rate limit and a burst rate limit per second for each method in your REST APIs and each route in WebSocket APIs. Further, API Gateway automatically protects your backend systems from distributed denial-of-service (DDoS) attacks, whether attacked with counterfeit requests (Layer 7) or SYN floods (Layer 3).”
- deleted 6y ago
  [deleted]
- alpha_squared 6y ago
  It's being attributed to API Gateway, but I think this is really just Cloudfront doing all that.
  - scarface74 6y ago
    CloudFront is just a CDN. APIGW let’s you create usage plans based on API Keys
mrmonkeyman 6y ago
Regular servers are not web-scale. Serverless is web-scale. It just works.
josho 6y ago
As developers we have done a poor job of managing complexity. Largely a result of schedule pressure that leads over time to code bases that have modules that reach deep into the internals of other modules. The consequence is a complex codebase that slows down development. So I believe serverless/micro services is a way to enforce those boundaries in such a way that a junior developer or schedule pressure won’t allow us to cheat and reach into the internals of another module to get a feature shipped in time. You simply can’t do that when code is running on a different server. So this additional complexity forces separation of concerns that can’t be cheated by schedule pressure or shortcuts. Of course the downside to this is we have to now manage a different kind of complexity. As developers I wish we pushed back and simply built our monoliths as a set of independent npm packages, jars, or whatever your language supports. Doing this enforces clear separation of interfaces / dependency management. If we did that then the complexity of debugging and supporting the architecture presented, which strikes me as several orders of magnitude more complex, would be avoided and instead we simply manage at our code level.
- deleted 6y ago
  [deleted]

empthought 6y ago

https://aws.amazon.com/api-gateway/faqs/ https://aws.amazon.com/api-gateway/faqs/ “ Q: How can I address or prevent API threats or abuse? API Gateway supports throttling settings for each method or route in your APIs. You can set a standard rate limit and a burst rate limit per second for each method in your REST APIs and each route in WebSocket APIs. Further, API Gateway automatically protects your backend systems from distributed denial-of-service (DDoS) attacks, whether attacked with counterfeit requests (Layer 7) or SYN floods (Layer 3).”

deleted 6y ago
[deleted]
alpha_squared 6y ago
It's being attributed to API Gateway, but I think this is really just Cloudfront doing all that.
- scarface74 6y ago
  CloudFront is just a CDN. APIGW let’s you create usage plans based on API Keys

mrmonkeyman 6y ago

Regular servers are not web-scale. Serverless is web-scale. It just works.

josho 6y ago

As developers we have done a poor job of managing complexity. Largely a result of schedule pressure that leads over time to code bases that have modules that reach deep into the internals of other modules. The consequence is a complex codebase that slows down development. So I believe serverless/micro services is a way to enforce those boundaries in such a way that a junior developer or schedule pressure won’t allow us to cheat and reach into the internals of another module to get a feature shipped in time. You simply can’t do that when code is running on a different server. So this additional complexity forces separation of concerns that can’t be cheated by schedule pressure or shortcuts. Of course the downside to this is we have to now manage a different kind of complexity. As developers I wish we pushed back and simply built our monoliths as a set of independent npm packages, jars, or whatever your language supports. Doing this enforces clear separation of interfaces / dependency management. If we did that then the complexity of debugging and supporting the architecture presented, which strikes me as several orders of magnitude more complex, would be avoided and instead we simply manage at our code level.

deleted 6y ago
[deleted]