11–20 of 112 posts
Earlier quoted context omitted.
Regardless of what you set Lambda concurrency to: Are you seriously invoking Lambdas for every page view?
We are indeed. Neither of us enjoy DevOps so we pay a premium to not have to manage servers. It brings a huge mental health benefit (we are a two person company), we're profitable and our monthly Lambda cost isn't that significant. Honestly, the biggest inefficiency (in terms of cost) is our use of SQS/RDS, which we are ditching soon.
Earlier quoted context omitted.
Regardless of what you set Lambda concurrency to: Are you seriously invoking Lambdas for every page view?
We are indeed. Neither of us enjoy DevOps so we pay a premium to not have to manage servers. It brings a huge mental health benefit (we are a two person company), we're profitable and our monthly Lambda cost isn't that significant. Honestly, the biggest inefficiency (in terms of cost) is our use of SQS/RDS, which we are ditching soon.
I'd be happy to help make this more efficient though (at no charge of course). Offhand I'd say "web server which accumulates data and uploads it to S3 every N requests or M seconds" would probably get you what you need at a tiny fraction of the cost of "lambda which posts to SQS". Create an AMI and toss it at an autoscaling group and you really won't need to worry about scaling issues either.
Earlier quoted context omitted.
We are indeed. Neither of us enjoy DevOps so we pay a premium to not have to manage servers. It brings a huge mental health benefit (we are a two person company), we're profitable and our monthly Lambda cost isn't that significant. Honestly, the biggest inefficiency (in terms of cost) is our use of SQS/RDS, which we are ditching soon.
Well, it's your money... I'd be happy to help make this more efficient though (at no charge of course). Offhand I'd say "web server which accumulates data and uploads it to S3 every N requests or M seconds" would probably get you what you need at a tiny fraction of the cost of "lambda which posts to SQS". Create an AMI and toss it at an autoscaling group and you really won't need to worry about scaling issues either.
For us, the cost works and we have appropriate margin for it. The cost savings aren't worth the extra "we have to monitor these servers" thoughts. Our approach is 100% emotional.
Earlier quoted context omitted.
Well, it's your money... I'd be happy to help make this more efficient though (at no charge of course). Offhand I'd say "web server which accumulates data and uploads it to S3 every N requests or M seconds" would probably get you what you need at a tiny fraction of the cost of "lambda which posts to SQS". Create an AMI and toss it at an autoscaling group and you really won't need to worry about scaling issues either.
I bet you could set up something way cheaper. And I'm certain you know 10x more than me regarding servers, hardening, configuration, etc. And I'm certain you enjoy servers! For us, the cost works and we have appropriate margin for it. The cost savings aren't worth the extra "we have to monitor these servers" thoughts. Our approach is 100% emotional.
The offer is open if you ever change your mind (e.g. if the cost becomes annoyingly large when you scale up further).
We're going to see a lot more of such attacks (Denial of Capital?) as engineers blindly throw more and more SaaS components together without any sort of rate limiting in place, especially so when those endpoints are publicly accessible and tied to your account (e.g. Firebase or Algolia requests that are billable to your conveniently included client-side API key). And in all honesty it's a lot easier to take a site of…
At present, we put all incoming page views into SQS Hmm, not the most economical of choices, but... We had decided that we were going to simply increase our lambda concurrency limit to 8,000,000 requests per second (800,000 concurrents) and handle the spam attacks ... wait, what? If you're using Lambda functions for something as trivial as logging page views , you evidently have more money than sense. The author is c…
Interesting that they won’t use Cloudflare due to competition in the analytics space. It makes me realize that there actually isn’t a legitimate competitor to Cloudflare and they are dominating right now.
We're going to see a lot more of such attacks (Denial of Capital?) as engineers blindly throw more and more SaaS components together without any sort of rate limiting in place, especially so when those endpoints are publicly accessible and tied to your account (e.g. Firebase or Algolia requests that are billable to your conveniently included client-side API key). And in all honesty it's a lot easier to take a site of…
Cloudflare at least will refund any extra costs incurred from their serverless product if you get DDOSed
Interesting that they won’t use Cloudflare due to competition in the analytics space. It makes me realize that there actually isn’t a legitimate competitor to Cloudflare and they are dominating right now.
Isn't Netlify a major competitor to Cloudflare?
At present, we put all incoming page views into SQS Hmm, not the most economical of choices, but... We had decided that we were going to simply increase our lambda concurrency limit to 8,000,000 requests per second (800,000 concurrents) and handle the spam attacks ... wait, what? If you're using Lambda functions for something as trivial as logging page views , you evidently have more money than sense. The author is c…
My main thought here is how important backpressure is for managing queues. We all hate to admit defeat, but sometimes shit is broken and you just have to say "sorry, service not available" and drop the requests on the floor. No buffer is infinitely long.