AWS Fargate Price Reduction(aws.amazon.com) |
AWS Fargate Price Reduction(aws.amazon.com) |
> At re:Invent 2018 we announced Firecracker, an open source virtualization technology that is purpose-built for creating and managing secure, multi-tenant containers and functions-based services. Firecracker enables you to deploy workloads in lightweight virtual machines called microVMs. These microVMs can initiate code faster, with less overhead. Innovations such as these allow us to improve the efficiency of Fargate and help us pass on cost savings to customers.
Also seeing interesting Firecracker developments around OSv (7ms boot times)[2] and Kata Containers[3]
1. https://firecracker-microvm.github.io/
Did anyone experience something similar? Or maybe I did something wrong?
If one of the benefits of firecracker is quick spin up time, then this only works if the load balancer also responds quickly doesn’t it?
Granted, it was a while ago so things might have changed.
However, now that we got it configured properly (took about 6 hours over the span of 3 days to catch the issues), we flawlessly serve 11M API requests/day without a problem. We were running these on DO boxes, moved it over to elastic beanstalk which caused more problems than it was worth, and finally landed on Fargate.
Tried EKS, but it was a bit more cumbersome than we would have liked for a K8s service. (We run another product of similar scale on K8s via GKE).
If you're looking for something closer to Heroku than K8s, then Fargate is decent option.
We adjust those down - somewhere 10-15 seconds for HealthCheckIntervalSeconds and 3 for HealthyThresholdCount works pretty well.
The Network Load Balancer is technically more scalable (able to accept more connections per second from the outside), but has a longer minimum inclusion time - 2 checks at a 10 second interval, so 20 seconds.
So yeah, you want slightly beefier containers, if you're scaling up and down heavily. But all this is pretty moot - whatever autoscaling parameters you set reaction time of CPU / RAM usage analysis is still going to be minutes. It seems like this is okay for now.
If you really want super fast scaling, use a Go function on Lambda (outside a VPC). With Firecracker improvements the cold start time should be barely noticeable, and you'll ramp up pretty quickly.
Next I'd like to see an equivalent to EC2's reserved instance pricing.
(There's some really good stuff in the signal processing field for anyone responsible for high-scale systems. An underrated branch of math for computer programmers. Believe it or not, the "fundamental limits" I'm referring to are the same ones involved in the Heisenburg Uncertainty Principle, when you get down into it.)