4 ms·

> Where normal web servers like Apache and Nginx have to sit idle 24/7, waiting for new requests to come in, with Zappa, the server is created after the HTTP re

by vog 11y ago

> Where normal web servers like Apache and Nginx have to sit idle 24/7, waiting for new requests to come in, with Zappa, the server is created after the HTTP request comes in through API Gateway To me, this sounds very much like reinventing the plain old CGI, just with different names ("Web server" -> "API Gateway", "CGI script" -> "server"). Am I missing something here?

Mizza 11y ago
You're not completely wrong, the difference is that there is no configuration necessary, no permanent infrastructure, no limitations on scalability, and the costs are measured in milliseconds. AWS just takes care of everything. It's just _python manage.py deploy prod_ and you're done. Obviously there are still ways that this can be optimized since Django wasn't really designed to be used like this, but it still seems performant enough for me, and the other advantages gained are major. Response times for a warm server are almost always <200ms, averaging just over 100ms (we did some tests on reddit yesterday.) In my own tests just now, I was getting <80ms response times consistently. And I'm certain there are ways that we can shave this down further.
- dexterdog 11y ago
  I get sub-100ms times quite often for light calls. The 'boot-up' call will always be longer, but that's because the service had gone idle. If you are getting heavy usage that is not an issue.
rakoo 11y ago
There are a few differences: * CGI is the closest UNIX thing you can find, fork a process, write on STDIN, read from STDOUT. Lambda actually is a framework for running javascript/java/python code, from which you can call actual binaries. * Lambda's attractive point is that containers are reused, which means that instead of paying the full price of a new process your context is already "hot", even for the actual binary you run. That means less latency and less CPU usage, allowing you to scale far more easily I'm no Lambda user so I'm possibly wrong, but the idea and execution behind sure looks nice.
- toomuchtodo 11y ago
  Both your statements are correct: Amazon is most likely running lxc containers under the hood though, so anyone could duplicate what Lambda does using an evaluator for javascript/python/etc with a REST API containerized in a docker container. Disclaimer: I am a heavy Lambda user.
  - Eridrus 11y ago
    I haven't done my own experiments, but reading the Lambda docs on Security has made me think these are real VMs and not containers.
metaphorm 11y ago
Lambda with the API Gateway (the Request/Response control flow, as opposed to the Event triggered control flow that Lambda uses with other services) is basically like a distributed, virtualized implementation of CGI. However, being distributed and virtualized is a pretty big deal. In practice this means Lambda apps perform differently than traditional CGI, and also require different app architecture to support them.

by vog 11y ago

Mizza 11y ago

You're not completely wrong, the difference is that there is no configuration necessary, no permanent infrastructure, no limitations on scalability, and the costs are measured in milliseconds. AWS just takes care of everything. It's just _python manage.py deploy prod_ and you're done. Obviously there are still ways that this can be optimized since Django wasn't really designed to be used like this, but it still seems performant enough for me, and the other advantages gained are major. Response times for a warm server are almost always <200ms, averaging just over 100ms (we did some tests on reddit yesterday.) In my own tests just now, I was getting <80ms response times consistently. And I'm certain there are ways that we can shave this down further.

dexterdog 11y ago
I get sub-100ms times quite often for light calls. The 'boot-up' call will always be longer, but that's because the service had gone idle. If you are getting heavy usage that is not an issue.

rakoo 11y ago

There are a few differences: * CGI is the closest UNIX thing you can find, fork a process, write on STDIN, read from STDOUT. Lambda actually is a framework for running javascript/java/python code, from which you can call actual binaries. * Lambda's attractive point is that containers are reused, which means that instead of paying the full price of a new process your context is already "hot", even for the actual binary you run. That means less latency and less CPU usage, allowing you to scale far more easily I'm no Lambda user so I'm possibly wrong, but the idea and execution behind sure looks nice.

toomuchtodo 11y ago
Both your statements are correct: Amazon is most likely running lxc containers under the hood though, so anyone could duplicate what Lambda does using an evaluator for javascript/python/etc with a REST API containerized in a docker container. Disclaimer: I am a heavy Lambda user.
- Eridrus 11y ago
  I haven't done my own experiments, but reading the Lambda docs on Security has made me think these are real VMs and not containers.

metaphorm 11y ago

Lambda with the API Gateway (the Request/Response control flow, as opposed to the Event triggered control flow that Lambda uses with other services) is basically like a distributed, virtualized implementation of CGI. However, being distributed and virtualized is a pretty big deal. In practice this means Lambda apps perform differently than traditional CGI, and also require different app architecture to support them.