4 ms·

Lambda was not designed for request/response. It’s an event driven service. Wrapping API gateway around it is an architectural blunder, and leads to folks like

Lambda was not designed for request/response. It’s an event driven service. Wrapping API gateway around it is an architectural blunder, and leads to folks like the GP wondering why their use case is a shitty fit.

fulafel 7y ago
Why is request/response not a fit for an event driven service in your view? A lot of request/response server apps are written using the event model.
- inopinatus 7y ago
  Trying to build synchronous out of asynchronous requires state machines, buffering, and overallocation of resources. It’s the enemy of scale. The two styles are an impedance mismatch.
  - toomuchtodo 7y ago
    I would read a deep dive blog post about this.
  - fulafel 7y ago
    Lambda is natively http based, no? Like all aws apis. It's just that it only speaks it's own json protocol, not generic web. Also request/response is not inherently synchronous or asynchronous. It's just a protocol design pattern. Buffering, overcommit, etc are also kust normal facts of life in both sync and async messaging.
    - inopinatus 7y ago
      No, it it natively event driven. Don’t confuse the control plane for the operational. Request/response is fundamentally synchronous. If you want to nitpick about other layers not blocking, that’s missing the wood for the trees.
  - markonen 7y ago
    There is nothing inherently asynchronous about the Lambda product, unless you’re talking about the Node.js runtime and even then that’s more about Node than about Lambda. Each Lambda invocation gets a dedicated VM for the duration of the request. It is a great match for synchronous code.
    - inopinatus 7y ago
      That is a mis-statement. Lambda executes functions in response to events. It is totally asynchronous with regards to its execution triggers. Lambda does reuse VMs, so I hope you aren’t relying on containers being discarded for any integrity or security outcomes. All the responses in this thread illustrate to me that AWS needs to put more effort into socialising how the product works. Since I was physically in the room for Lambda’s AWS internal launch this is twice disappoint because the technical messaging then was very clear and compelling.
mlthoughts2018 7y ago
“function as a service” absolutely does need to support request/response as a primary use case.
- deleted 7y ago
  [deleted]

fulafel 7y ago

Why is request/response not a fit for an event driven service in your view? A lot of request/response server apps are written using the event model.

inopinatus 7y ago
Trying to build synchronous out of asynchronous requires state machines, buffering, and overallocation of resources. It’s the enemy of scale. The two styles are an impedance mismatch.
- toomuchtodo 7y ago
  I would read a deep dive blog post about this.
- fulafel 7y ago
  Lambda is natively http based, no? Like all aws apis. It's just that it only speaks it's own json protocol, not generic web. Also request/response is not inherently synchronous or asynchronous. It's just a protocol design pattern. Buffering, overcommit, etc are also kust normal facts of life in both sync and async messaging.
  - inopinatus 7y ago
    No, it it natively event driven. Don’t confuse the control plane for the operational. Request/response is fundamentally synchronous. If you want to nitpick about other layers not blocking, that’s missing the wood for the trees.
- markonen 7y ago
  There is nothing inherently asynchronous about the Lambda product, unless you’re talking about the Node.js runtime and even then that’s more about Node than about Lambda. Each Lambda invocation gets a dedicated VM for the duration of the request. It is a great match for synchronous code.
  - inopinatus 7y ago
    That is a mis-statement. Lambda executes functions in response to events. It is totally asynchronous with regards to its execution triggers. Lambda does reuse VMs, so I hope you aren’t relying on containers being discarded for any integrity or security outcomes. All the responses in this thread illustrate to me that AWS needs to put more effort into socialising how the product works. Since I was physically in the room for Lambda’s AWS internal launch this is twice disappoint because the technical messaging then was very clear and compelling.

mlthoughts2018 7y ago

“function as a service” absolutely does need to support request/response as a primary use case.

deleted 7y ago
[deleted]