71–80 of 89 posts
Earlier quoted context omitted.
Fargate isn't a competitor to Cloud Run (I wish it was) because it doesn't scale to zero in between requests and scale back up again when new traffic arrives.
Check out AWS App Runner. It may do exactly what you’re looking for.
That doesn't sound like the automated scale-to-zero I get from Cloud Run.
Lots of interesting work is being done in this area (Currently doing research around serverless at the moment). Cold start up times still remain a pretty large issue (125ms start up for VM is still quite large) but some interesting papers trying to attack this, through strategies like snapshotting! https://arxiv.org/pdf/2101.09355.pdf Also predicting function calls to properly schedule and reduce cold start latency h…
You can also avoid the cold start penalties entirely, if you're willing to pay extra for provisioned concurrency [1].
[1]: https://docs.aws.amazon.com/lambda/latest/dg/configuration-c...
Earlier quoted context omitted.
From what I know there is a secret sauce beyond a mere AMI and a control plane, based on some EBS volumes magic. I may be mixing things up with Aurora though.
There were some comments in the early days that the Multi-AZ magic for classic RDS was just drbd on top of EBS. Aurora is a completely different approach where the RDBMS code is modified to directly interface with EBS instead of going through a traditional OS filesystem layer.
If this was true, then you could support multiple database vendors in a generic way, and gradually add the supported products, without knowing the intricacies of each product's replication details. Hmm. :)
Earlier quoted context omitted.
> I wish Fargate was easier to use and had a scale to 0 feature. Fargate can be scaled to zero. Also, have you tried the CLI? [0] [0]: https://github.com/aws/copilot-cli
When I say "scale to zero" I mean like Cloud Run or AWS Lambda: I define it as the service automatically scaling to zero (and hence costing nothing to run) in between requests, but automatically starting up again when a new request comes in - so the request still gets served, it just suffers from a few seconds of cold-start time. I'm pretty sure Fargate doesn't offer this. It sounds like you're talking about the abil…
One other thing I learned here is that lambda@edge is not actually run on the edge at all. It is forwarded to the nearest datacenter to execute. Not enough capacity in edges to spin up entire VMs for everything, even with Firecracker.
They do have Cloudfront Functions now for real Edge compute: https://aws.amazon.com/blogs/aws/introducing-cloudfront-func...
Their JS engine seems quite odd, they selectively have very modern features but not let/const o_0
Earlier quoted context omitted.
Check out AWS App Runner. It may do exactly what you’re looking for.
"Easily pause and resume your App Runner applications using the console, CLI, or API. You’re only billed when the service is running." That doesn't sound like the automated scale-to-zero I get from Cloud Run.
Lots of interesting work is being done in this area (Currently doing research around serverless at the moment). Cold start up times still remain a pretty large issue (125ms start up for VM is still quite large) but some interesting papers trying to attack this, through strategies like snapshotting! https://arxiv.org/pdf/2101.09355.pdf Also predicting function calls to properly schedule and reduce cold start latency h…
These 125ms are only the startup time of the MVM and don't include additional latency introduced by optimizing the code package and the involvement of the placement service. You can also avoid the cold start penalties entirely, if you're willing to pay extra for provisioned concurrency [1]. [1]: https://docs.aws.amazon.com/lambda/latest/dg/configuration-c...
Obviously, one could eliminate the cold start issue in general by just constantly paying for a running EC2 instance.
But cold start is still an issue for the provider as cold start is a cost to them, even reducing cold start of internal runtimes would be a massive benefit (For example pre-warmed JITs). Better cold start times means better bin packing for their services, and overall less cost to everyone.
Earlier quoted context omitted.
To build a new service at Amazon, the general path of least resistance these days is to use Lambda. If not Lambda, then ECS. If not ECS (or if it requires bare metal) then EC2.
Yeah, except for the lambda time limit...