3 ms·

Did they just inadvertently point out why this is a bad idea for anything general-purpose?

derefr 9y ago
Not really; those are exactly the sort of config settings you'd sensibly use to prevent someone from DDoSing your untrusted prototype-level infrastructure. If your VMs are truly cheap, and you've ironed out the kinks from your proof-of-concept, you'd obviously set up your production system to run more than 16 of them.
- deleted 9y ago
  [deleted]
- StreamBright 9y ago
  Right, and who decides that a request coming from a customer ot an attacker? If the attacker can generate enough requests non of the customers have a chance to use your service. This is absolutely not the way to handle DDoS.
  - derefr 9y ago
    My point was that it's a sensible strategy for the demo of a technology that's still under development (like this project), where you don't actually have any "customers." In production, you'd let it scale unboundedly, and combine it with some sort of anti-DDoS technology like Cloudflare.
Dylan16807 9y ago
It depends on how many resources it takes to run those 16 instances. If it's an extremely small demo allocation, then that's not a big deal. If it's multiple gigabytes and cores then the efficiency is awful.
rozap 9y ago
The point is to show boot times. If you are scaling up/down in response to load, this is a nice quality to have. Most folks have really spiky traffic patterns so this can save you a lot of money. Obviously no one would ever run something like this 1 vm per request thing irl.
- ComodoHacker 9y ago
  Never say never...
- notzorbo3 9y ago
  > Obviously no one would ever run something like this 1 vm per request thing irl. I can see plenty of use-cases for doing just that. Large uploads, time-consuming request/responses such as server-side data processing, RPC, as a backend behind a caching front-end so that it only has to respond to invalidated cache entries, etc. I don't see many people using this to actually serve general website requests though. It'd probably be modified to serve multiple requests until nothing is left to do and then exit.

Not really; those are exactly the sort of config settings you'd sensibly use to prevent someone from DDoSing your untrusted prototype-level infrastructure. If your VMs are truly cheap, and you've ironed out the kinks from your proof-of-concept, you'd obviously set up your production system to run more than 16 of them.

deleted 9y ago
[deleted]
StreamBright 9y ago
Right, and who decides that a request coming from a customer ot an attacker? If the attacker can generate enough requests non of the customers have a chance to use your service. This is absolutely not the way to handle DDoS.
- derefr 9y ago
  My point was that it's a sensible strategy for the demo of a technology that's still under development (like this project), where you don't actually have any "customers." In production, you'd let it scale unboundedly, and combine it with some sort of anti-DDoS technology like Cloudflare.

Dylan16807 9y ago

It depends on how many resources it takes to run those 16 instances. If it's an extremely small demo allocation, then that's not a big deal. If it's multiple gigabytes and cores then the efficiency is awful.

rozap 9y ago

The point is to show boot times. If you are scaling up/down in response to load, this is a nice quality to have. Most folks have really spiky traffic patterns so this can save you a lot of money. Obviously no one would ever run something like this 1 vm per request thing irl.

ComodoHacker 9y ago
Never say never...
notzorbo3 9y ago
> Obviously no one would ever run something like this 1 vm per request thing irl. I can see plenty of use-cases for doing just that. Large uploads, time-consuming request/responses such as server-side data processing, RPC, as a backend behind a caching front-end so that it only has to respond to invalidated cache entries, etc. I don't see many people using this to actually serve general website requests though. It'd probably be modified to serve multiple requests until nothing is left to do and then exit.