151–160 of 233 posts
Earlier quoted context omitted.
You could make a fortune selling that by itself, unless your ops cost is just yolo provisioning and never doing backups/patching/etc.
I'll never understand how we got to this point of learned helplessness where people think hosted services like Lambda are the only ones capable of being secure and robust. It's madness..
Earlier quoted context omitted.
There is actually a really awesome middle-ground that AWS offers that no one seems to talk about. That is using ECS + Fargate. This gives you (IMHO) the best of both worlds between Lambda and EC2. ECS is Elastic Container Service. Think docker/podman containers. You can even pull from Dockerhub or ECR (Elastic Container Registry - amazon's version of dockerhub). ECS can then deploy to either a traditional EC2 compute…
>It has automatic scaling, so it can scale up and down with traffic (all of which is configured in ECS) Doesn't scaling take time, though? Doesn't downloading a new docker container definition and starting it take at least as long as initializing a new lambda function? Also with lambda there's no configuring to do for scaling. If anything lambda gives you tools to limit the concurrency.
- Relatively poor amortized scale out time with good guarantees in the worst case.
- Good amortized scale out time with dropped requests / timeouts in the worst case.
With lambda, it doesn't really matter how spiky the traffic is. Users will see the cold start latency, albeit more often. With Fargate, users won't run into the cold start latencies - until they do, and the whole request may timeout waiting for that new server to spin up.
At least that seems to be the case to me. I have personally never ran a docker image in fargate, but I'd be surprised if it could spin up, initialize and serve a request in two seconds.
Earlier quoted context omitted.
There is actually a really awesome middle-ground that AWS offers that no one seems to talk about. That is using ECS + Fargate. This gives you (IMHO) the best of both worlds between Lambda and EC2. ECS is Elastic Container Service. Think docker/podman containers. You can even pull from Dockerhub or ECR (Elastic Container Registry - amazon's version of dockerhub). ECS can then deploy to either a traditional EC2 compute…
>It has automatic scaling, so it can scale up and down with traffic (all of which is configured in ECS) Doesn't scaling take time, though? Doesn't downloading a new docker container definition and starting it take at least as long as initializing a new lambda function? Also with lambda there's no configuring to do for scaling. If anything lambda gives you tools to limit the concurrency.
Yes, especially because they still don't support caching the image locally for Fargate. If you start a new instance with autoscaling, or restart one, you have to download the full image again. Depending on its size, start times can be minutes...
Also, what is up with Python being faster than Node in the beginning and then getting slower over time? The other languages (apart from graal) get faster over time. I'm referring to the average MS latency at 128MB graph at the bottom.
Honestly shocked that rust is about 4 times faster than node for the DynamoDB insert workload in the average case. I knew it'd be faster but I would have expected maybe 50% faster since most of the time is probably spent simply sending the data to dynamoDB and awaiting a response. Also, what is up with Python being faster than Node in the beginning and then getting slower over time? The other languages (apart from gr…
Earlier quoted context omitted.
I'll never understand how we got to this point of learned helplessness where people think hosted services like Lambda are the only ones capable of being secure and robust. It's madness..
That's not what I said or implied.
> your ops cost is just yolo provisioning and never doing backups/patching.
You think Amazon is the only one capable of doing backups and keeping software up to date?
The best cold starts are those which aren't noticed by the user. For my blog search (which runs on Lambda), I found a nice way of achieving that [1]: as soon as a user puts the focus to the input field for the search text, this will already submit a "ping" request to Lambda. Then, when they submit the actual query itself, they will hit the already running Lambda most of the times. And, as others said, assigning more…
1 - https://aws.amazon.com/blogs/aws/new-provisioned-concurrency...
I'm surprised Node has cold-start issues. I had it in my mind that JS was Lambda's "native" language and wouldn't have cold start issues at all. Did it used to be like that? Didn't Lambda launch with only support for JS, and maybe a couple other languages that could compile to it?
I wonder ho w much time was spent requiring all of aws-sdk. The v3 sdk is modular and should be quicker to load. Bundlers like rebuild save space and reduce parsing time.
Earlier quoted context omitted.
So effectively you're going to pay double?
You increase the usage of the lambda, sure, but not by double unless all this lambda does is respond to the search. There's a point where this is all semantics when running cloud services with regard to how you've deployed your code behind gateways and lambdas, but most applications have obvious triggers that could warm up a lambda at 10% or less overhead. And even then....lambdas are dirt cheap.