Awesome to see Firecracker[1] already bearing fruit:
> 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]
I played around with fargate and one of the things I couldn’t work out is scaling quickly (or quick-enough). I think the problem wasn’t purely fargate but actually the load balancer. Even though containers were launched and responsive, the load balancer needed something like 3 liveness responses to bring it into the pool, and the time between each probe was something like 30 or 10 seconds and not very flexible (sorry, my memory is fuzzy)... so this felt like it only really fits loads that aren’t very spikey and also the potential saving from scaling down is somewhat reduced.
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.
Fargate definitely takes some time to figure out. It took a while for us to realize that we needed to bump up our instance sizes because the default instance was a t2.micro.
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.
Glad to see this, Fargate was a pretty steep premium. Comparing an on-demand m5.large to the equivalent Fargate container looks to be a 20% premium, which seems reasonable.
Next I'd like to see an equivalent to EC2's reserved instance pricing.
talawahdotnet|7 years ago
> 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/
2. https://twitter.com/osvdev/status/1081461689139281920
3. https://twitter.com/egernst/status/1076308458335494144
gingerlime|7 years ago
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.
apandhi|7 years ago
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.
itwasntandy|7 years ago
We adjust those down - somewhere 10-15 seconds for HealthCheckIntervalSeconds and 3 for HealthyThresholdCount works pretty well.
luhn|7 years ago
Next I'd like to see an equivalent to EC2's reserved instance pricing.
cflat|7 years ago
vdm|7 years ago
mitgraduate|7 years ago
[deleted]